Erro de gatilho do Gmail

Descreva o problema/erro/pergunta

Problema no nó Gmail Trigger: Estou enfrentando um problema com meu fluxo de trabalho usando o nó Gmail Trigger na versão 2.20.7 do n8n e era o mesmo na 2.20.6. Meu fluxo está configurado para pesquisar emails não lidos a cada minuto, agora defini para 5 min para não sobrecarregar a contagem de execuções, mas ele está contando execuções mesmo quando nenhum email não lido é encontrado, o que também está registrando como erro na aba de execução. Esse comportamento é diferente da versão 2.16, onde tais casos não eram contados como execuções. Como posso configurar meu fluxo de trabalho para que ele não conte execuções quando nenhum email é encontrado? Por enquanto estou capturando esse tipo específico de erro e configurando como nada, minha única preocupação é que está aumentando minha contagem de execuções e dessa forma vou ultrapassar o limite mensal. Notei esse problema quando atualizei ontem da 2.16.# para 2.20.6 como estável mais recente e hoje para 2.20.7 como estável mais recente.

Qual é a mensagem de erro (se houver)?

Nenhum erro específico, apenas mostra: Problema no nó ‘Gmail Trigger’ e em outras informações mostra os detalhes da consulta de busca como causa

[
{
“trigger”: {
“error”: {
“name”: “IsolateError”,
“cause”: {
“q”: “=from:@domain.com -from:group@domain.com newer_than:1d”,
“readStatus”: “unread”
}
},
“mode”: “trigger”
},
“workflow”: {
“id”: “#####”,
“name”: “Gmail Workflow Name”
}
}
]

Por favor, compartilhe seu fluxo de trabalho

Observe que substitui os IDs, nomes e endereços de email com dados fictícios ou #### para não liberar acidentalmente detalhes confidenciais.

(Selecione os nós em sua tela e use os atalhos de teclado CMD+C/CTRL+C e CMD+V/CTRL+V para copiar e colar o fluxo de trabalho.)
{
  "nodes": [
    {
      "parameters": {
        "pollTimes": {
          "item": [
            {
              "mode": "everyX",
              "value": 5,
              "unit": "minutes"
            }
          ]
        },
        "maxResults": 1,
        "filters": {
          "q": "==from:@domain.com -from:group@domain.com newer_than:1d",
          "readStatus": "unread"
        }
      },
      "type": "n8n-nodes-base.gmailTrigger",
      "typeVersion": 1.4,
      "position": [
        656,
        1104
      ],
      "id": "#####,
      "name": "Group Gmail Trigger",
      "alwaysOutputData": false,
      "notesInFlow": false,
      "credentials": {
        "gmailOAuth2": {
          "id": "####",
          "name": "Gmail Group Support Gmail2"
        }
      }
    }
  ],
  "connections": {
    "Group Gmail Trigger": {
      "main": [
        []
      ]
    }
  },
  "pinData": {},
  "meta": {
    "templateCredsSetupCompleted": true,
    "instanceId": "#####"
  }
}

Compartilhe o resultado retornado pelo último nó

Detalhes do erro
Outras informações
Versão do n8n
2.20.7 (Cloud)
Causa do erro
{ “q”: “=from:@domain.com -from:group@domain.com newer_than:1d”

Informações sobre sua configuração de n8n

  • Versão do n8n: 2.20.7
  • Banco de dados (padrão: SQLite):
  • Configuração EXECUTIONS_PROCESS do n8n (padrão: own, main):
  • Executando n8n via (Docker, npm, n8n cloud, aplicativo desktop): n8n cloud
  • Sistema operacional:

Espero por qualquer insight ou se este é um erro que requer correção por quem mantém o nó Gmail Trigger ou pela versão do n8n?

Obrigada,

Nidhi Patel

5x12x24x31 = 44640 execuções por mês

Acredito que este é o comportamento correto, já que o fluxo de trabalho é acionado

Obrigado, @kjooleng - mas anteriormente não era o caso, e por outro lado, está lançando como um erro, o que também é um comportamento incomum. alguma sugestão sobre isso?

Obrigado,

NP

Oi @nidhi-patel! Ótima pergunta sobre a parte do erro especificamente.

Sobre a mudança de comportamento da v2.16: você está certo que isso mudou. Em versões anteriores, triggers de polling que não encontravam resultados saíam de forma limpa sem registrar uma execução. A partir da v2.17+ em diante, cada ciclo de polling é registrado como uma execução independentemente de ter encontrado algo. Essa foi uma mudança deliberada para observabilidade, embora tenha o efeito colateral que você está vendo em planos cloud com limites de execução.

Sobre o erro sendo lançado: o IsolateError que você está vendo provavelmente não é um erro da Gmail API, mas sim n8n internamente lançando porque o nó recebeu 0 resultados e o tratamento de erro do trigger está exibindo isso como um evento de erro. Algumas coisas para tentar:

  1. Nas configurações do nó Gmail Trigger, verifique se há uma opção “On Error” (Ao Errar). Defina como “Continue” se disponível.
  2. Alternativamente, mude do nó Gmail Trigger para um Schedule Trigger que dispara a cada 5 minutos, seguido por um nó Gmail no modo “Get Many” (Obter Muitos) com sua query de filtro. Depois adicione um nó IF para verificar se o array de resultados está vazio antes de continuar. Isso te dá controle total e o schedule trigger em si não lança erro em resultados vazios.

A abordagem Schedule + Gmail Get Many é na verdade mais flexível a longo prazo, já que você pode adicionar lógica de retry, filtrar com mais precisão, e é mais fácil de debugar.

Espero ter ajudado!

Obrigado @nguyenthieutoan, aprecio a explicação. Eu já tenho o que você sugeriu em vigor, mas não fico feliz em ver um erro quando há “No New Email” com o Gmail Trigger Node e o engraçado é que está dizendo que a query é a causa, então a mensagem de erro está errada e também é enganosa, passei muito tempo confirmando se o formato da query foi alterado pelo Google.

Acho que no máximo não deveria ser registrado como um erro, pois não é. E possivelmente ter outra abordagem, talvez como um Info ou até mesmo um warning ou simplesmente registrá-lo. O outro problema para mim é que está sendo contado como uma execução e não tendo um encerramento limpo, o que também me força indiretamente a ceder para atualizar o plano, ou optar por auto-hospedagem. Acho que esse é um grande aprendizado para mim neste cenário. Como antes eu estava no Gmail Trigger Node v1.2, atualizei para v1.4, mas tudo que fez foi adicionar a configuração de máximo de itens por poll. Também antes de atualizar, o changelog não mostra muito detalhes que eu caísse neste problema, não consegui testar antes de atualizar, foi um grande erro.

A configuração que tenho é:

1: Gmail Trigger Node: Settings → On Error: stop workflow, e um nó que verifica se tem um id legítimo, então uso o id para obter a mensagem completa via API para processar ainda mais.

-> A próxima coisa que posso tentar é adicionar um loop, para que eu possa fazer um loop através dos novos e-mails que não foram processados e empurrar os acionadores de execução de 5 min para 30 min para diminuir a execução, se for aprovado internamente.

2: Workflow de erro ao qual tive que adicionar um cenário especial para não acionar notificação de acompanhamento em canais subsequentes para corrigir o erro.

Não tenho certeza, mas não consigo encontrar uma forma de reverter para uma versão mais antiga.

Talvez a equipe do n8n possa avaliar e ver se isso tem valor:

-> Para manter os logs de execução limpos e não registrar quando nenhum e-mail é encontrado como um erro, pois na realidade não é um erro. Assim, apenas então ajudará com uma investigação significativa de erros reais, quando necessário.

-> Para que o nó Gmail Trigger tenha um encerramento limpo

-> Não contar como uma execução quando não há erro, pois na realidade é o webhook verificando novos e-mails, o fluxo inteiro não precisa ser executado.

De qualquer forma, obrigado pelos detalhes que você compartilhou. Aprecio. Por favor, me avise se há qualquer outra abordagem que eu deveria tentar.

Atenciosamente,

NP

Você consegue fazer isso?

O menu suspenso deve permitir que você altere versões

Você levantou pontos muito válidos aqui, NP, e honestamente esse tipo de análise detalhada é exatamente o que o time da n8n precisa ouvir.

Você está completamente certo de que registrar um cenário “sem novo email” como um erro é enganoso. Não é um erro em nenhum sentido significativo, é apenas um ciclo de polling que não encontrou nada. O fato de que isso também conta como uma execução e a mensagem de erro aponta para “query” como a causa torna tudo ainda mais confuso e tem implicações reais de custo nos planos em nuvem.

Algumas coisas que podem ajudar enquanto isso:

Sobre a contagem de erros: Se você mudar seu Gmail Trigger “On Error” de “Stop Workflow” para “Continue” (ignorar erros), o ciclo de polling ainda acontece, mas não aparecerá como uma execução falhada no seu workflow de erros. Isso reduz o ruído no rastreamento de erros, mesmo que não corrija a contagem de execuções em si.

Sobre a versão: A dica do @kjooleng sobre o dropdown de versão é o caminho certo se você está no n8n cloud. Você pode tentar selecionar 2.19.5 ou qualquer versão que estava estável antes dessa mudança de comportamento.

Mais importante: Eu encorajaria fortemente você a enviar isso como uma solicitação de feature/bug no GitHub em Issues · n8n-io/n8n · GitHub . Sua análise aqui já é muito clara e bem estruturada. Os três pontos que você listou:

  • Não registre polls vazios como erros
  • Comportamento de pausa limpa para Gmail Trigger
  • Não conte polls sem resultado como execuções

…são melhorias genuinamente razoáveis de UX e o time realmente age conforme o feedback bem documentado da comunidade. Quanto mais pessoas votarem ou +1, melhor a chance de ser priorizado.

Espero que isso ajude a avançar as coisas para você!

Obrigado @kjooleng, não tenho a versão que você sugeriu, por favor, encontre o snapshot anexado…

Me avise se há outra forma.

Abração,

NP

Obrigado @nguyenthieutoan, vou criar uma issue baseado na sua sugestão, espero que isso ajude a resolver. Enquanto isso, vou ver como consigo diminuir a frequência do Gmail Trigger.

Apreço sua orientação clara.

Abs,

NP

Oi @nidhi-patel

Verifiquei as issues do GitHub mais próximas que consegui encontrar, e nenhuma delas parece estar aberta agora. As mais próximas estão relacionadas a polling de Gmail Trigger, tratamento de emails não lidos, ou diferenças entre comportamento de trigger manual e automático, mas elas não descrevem este caso exato em que uma sondagem vazia é registrada como um erro e contada como uma execução. O ponto-chave que eu reportaria é que uma sondagem vazia não deveria ser contada ou registrada como uma execução falhada, porque “nenhum email novo” é um estado válido de trigger, não um erro operacional.

Ótimo ponto de @tamy.santos! Essa abordagem está perfeita: “sem novo e-mail” é realmente apenas um estado normal de inatividade, não um erro. Reportar isso ao GitHub é definitivamente o caminho certo, @nidhi-patel.

Enquanto isso, reduzir a frequência de polling, como você mencionou, deve ajudar a manter sua contagem de execuções sob controle. Se sentir que as orientações aqui ajudaram a esclarecer a solução alternativa e os próximos passos, sinta-se à vontade para marcar a resposta mais útil como Solução, para que outras pessoas com a mesma dúvida possam encontrá-la rapidamente!