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:
-
A cada email processado com sucesso, escreva
last_processed_at = NOW()em uma única linha em uma Google Sheet ou base do Airtable. -
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.”
-
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.