Gatilho de Email (IMAP) apenas para — sem erro, fluxo de trabalho ainda aparece como publicado

Perguntas
,
1

Nosso trigger IMAP tem falhado a cada poucos dias e finalmente descobri o porquê, então estou compartilhando caso alguém esteja enfrentando a mesma coisa.

O sintoma: o trigger simplesmente para de buscar. Sem erro, sem execução de Workflow de Erro, workflow ainda aparece como publicado. E-mails ficam não lidos até que alguém perceba e republique manualmente. Estamos no n8n Cloud com Gmail — vale mencionar, porque todos os outros relatos disso que consegui encontrar são auto-hospedados, então isso continua sendo descartado como um firewall de alguém.

O que me fez entender foi ver os dois modos de falha no mesmo workflow em dois dias seguidos. No dia 10 às 19:17Z a conexão caiu, n8n levantou IMAP connection closed unexpectedly, desativou o workflow, reativou automaticamente, e estávamos processando novamente cerca de 2,5 horas depois — exatamente o que você gostaria. No dia 11 às 13:20Z caiu novamente e nada aconteceu. Sem erro, sem desativação, sem retry. Dezessete horas depois o workflow ainda estava lá marcado como ativo com e-mails não lidos na caixa.

Mesma configuração em ambos os casos, então não é ambiental — é em qual branch a desconexão aconteceu de atingir. É handleReconnect: define isCurrentlyReconnecting = true, que por acaso é exatamente a flag que o manipulador close verifica antes de emitir um erro, e depois envolve toda a reconexão em um catch que apenas escreve no log. Então se restabelecer a conexão falhar, o nó já silenciou seus dois canais de erro, e fica quieto permanentemente enquanto a UI ainda diz publicado.

Existe uma issue no GitHub para isso — #30871, aberta desde maio, sem PR ainda.

Uma coisa que nos custou leads reais, e não vi escrito em lugar nenhum: não apenas republique para se recuperar. Expressões de trigger são avaliadas uma vez, quando o workflow é ativado. Se você tem um SINCE dinâmico em Regras de E-mail Personalizadas, fica congelado naquele momento — republicar reseta para hoje, e tudo da janela de indisponibilidade é pulado para sempre. Puxe o backlog com uma busca mais ampla primeiro, depois republique.

Então, alguém está realmente rodando o trigger IMAP de forma confiável a longo prazo? Ou todo mundo silenciosamente mudou para o nó Gmail em um trigger Schedule? Estou prestes a fazer o último, mas preferiria não fazer se houver uma configuração que perdi.

n8n Cloud 2.33.7, IMAP trigger typeVersion 2.1, Gmail na porta 993, forceReconnect 60.

2

Oi @oskar_dybas, enquanto você espera por uma resposta, aqui estão algumas coisas que podem ajudar:

Recursos sugeridos

Automaticamente correspondido à sua pergunta.

Docs:

Fórum:

@kjooleng, @krisn0x - vocês já ajudaram com problemas semelhantes antes, podem dar uma olhada?

Sugerido automaticamente pelo bot da comunidade n8n. É um piloto - por favor compartilhe feedback aqui.

3

Oi @oskar_dybas

parece ser a melhor opção porque:

  1. O nó Gmail usa requisições HTTP padrão por meio de polling, que são muito mais resilientes aos erros “conexão fechada inesperadamente” que afligem conexões IMAP de longa duração.
  2. Se uma requisição HTTP falhar, o nó Gmail lançará um erro padrão, que o n8n pode capturar por meio de um Fluxo de Erro.
  3. Ao pesquisar por is:unread em vez de “desde a hora X”, você garante que, mesmo que o fluxo falhe por várias horas, a próxima execução bem-sucedida pegará todos os emails não lidos na caixa de entrada.
4

Obrigado por nos informar sobre isso. Criamos NODE-5741 como o ticket interno de desenvolvimento para investigar.

5

Oi @oskar_dybas
O nó expõe apenas Custom Email Rules e Force Reconnect Every Minutes, portanto não há uma configuração que alcance essa ramificação.
Um workflow de watchdog cobre isso, já que a travagem é invisível de dentro do workflow afetado. Acione o gatilho de agendamento a cada 15 minutos, nó n8n com Execution > Get Many filtrado para o workflow IMAP, Limit 1. Se o startedAt mais recente for mais antigo que seu limite, execute o nó n8n novamente com Workflow > Unpublish e depois Workflow > Publish nesse workflow para forçar uma conexão nova, e alerte na mesma ramificação. A chave de API vem de Settings > n8n API.
Dois detalhes o tornam confiável. Tenha um segundo workflow Schedule que verifique a caixa de entrada a cada 10 minutos, então nenhuma execução significa inativo em vez de silencioso. E mantenha Custom Email Rules estático, o republish do watchdog reavalia as expressões de gatilho exatamente como um manual faria e redefinaria um SINCE dinâmico.

6

Uma ressalva antes de transformar o contorno desabilitar/habilitar em um cão de guarda automático: ele pode restaurar o socket, mas também pode reavaliar uma regra dinâmica `SINCE` e mover a janela de recuperação para além de mensagens que chegaram durante a interrupção.

Eu usaria o cão de guarda para alertar primeiro, depois recuperar nesta ordem:

  1. Tirar um snapshot ou listar o backlog não lido da interrupção e manter os IDs de mensagem do provedor para deduplicação.
  2. Enviar uma sonda sintética de uma segunda caixa de correio para provar que a caixa de entrada está saudável enquanto o gatilho n8n está silencioso.
  3. Ampliar a consulta de recuperação antes de republicar, depois reconciliar cada mensagem da janela de interrupção com exatamente uma ação downstream.
  4. Para Gmail, mover a conexão IMAP de longa duração para Schedule Trigger + pesquisa/polling do Gmail, com uma verificação externa de homem morto para a execução bem-sucedida mais recente.

Escrevi a sequência completa de recuperação com backlog primeiro aqui, com links para #30871, NODE-5741, histórico de execução e referências de Error Workflow: n8n IMAP Trigger Stops Silently: Recovery Guide | Resilient Flows

É um guia de incidentes gratuito. Nenhum login de produção ou credenciais são necessários.

7

Excelente análise de causa raiz — a condição de corrida entre handleReconnect / isCurrentlyReconnecting é sutil e o fato de que silenciosamente desativa ambos os canais de erro é o que a torna tão perigosa em produção.

Uma coisa que vale a pena adicionar junto com a migração Gmail+Schedule: um comutador de último recurso para qualquer trigger que você use. O bug do IMAP é um bom lembrete de que a UI do n8n pode mostrar “Publicado” enquanto o trigger está surdo, então você não pode contar apenas no log de execução.

O padrão que uso para fluxos de trabalho de email em produção:

  1. A cada email processado com sucesso, escreva last_processed_at = NOW() em uma única linha em uma Google Sheet ou base do Airtable.

  2. Um fluxo de trabalho agendado separado é executado a cada 2 horas: lê esse timestamp, verifica se é anterior a 4 horas (ajuste ao seu volume esperado de emails). Se sim → alerta Slack/email: “O fluxo de trabalho de email pode estar travado.”

  3. Se você ficar silencioso (fim de semana, tráfego baixo) você pode pausar a verificação ou definir um limite de tempo maior.

Dessa forma, mesmo que o trigger morra silenciosamente e a UI minta, você descobre em 2 horas em vez de “quando alguém notar”.

O padrão mais amplo (e algumas outras armadilhas “fluxo de trabalho bem-sucedido, mas não faz nada”) está em um post que escrevi semana passada: The silent failure: when your n8n workflow succeeds but does nothing — a seção de heartbeat no final é diretamente relevante aqui.

Se você está executando fluxos de trabalho de email em produção e quer que outra pessoa seja responsável pela camada de confiabilidade, meu time na Occelatus faz trabalho DFY com n8n — fico feliz em ajudar de qualquer forma.

8

Na rota do Gmail com Schedule, não faça a query usando is:unread. Qualquer pessoa que abra a caixa de correio marca uma mensagem como lida e ela desaparece silenciosamente da busca, o que é o mesmo tipo de problema de backlog perdido que o SINCE congelado que você descreveu. Use um rótulo como marcador de processamento: nó do Gmail com Get Many e uma busca de -label:n8n-processed, depois uma etapa Gmail Add Label to Message no final da ramificação, para que uma execução que falhe no meio deixe a mensagem elegível na próxima pesquisa e um backlog de indisponibilidade seja drenado automaticamente sem uma query de recuperação ampliada. Teste-o com uma mensagem que você já tenha lido e confirme que a próxima pesquisa ainda a seleciona.

9

O watchdog de despublicação/publicação de Anshul tem a forma correta. Trilho extra do caso de perda de lead de Oskar: recusar republicação automática se Custom Email Rules contiver um SINCE dinâmico. Essa expressão é avaliada no momento da ativação, então um bounce redefine a janela para hoje e o email de interrupção desaparece para sempre. Alertar primeiro, drenar a fila, depois fazer bounce.