Um workflow com dois nós de gatilho permanentes — Email Trigger (IMAP) (v2.2) e Telegram Trigger (v1.5) — ativa-se com sucesso (workflow mostra active: true), mas o gatilho IMAP nunca processa novos e-mails de entrada em produção. O gatilho Telegram no mesmo workflow funciona perfeitamente.
Passos para reproduzir:
Workflow está ativo, ambos os gatilhos registrados.
Novo e-mail é enviado para a caixa de correio IMAP monitorada.
E-mail permanece não lido na caixa de correio.
Nenhuma execução de workflow é criada (nem mesmo uma falha).
“Test step” manual no nó do gatilho IMAP funciona perfeitamente (confirma credenciais válidas) — mas é apenas um teste de nó individual, não o gatilho em tempo real.
Já descartado:
Credenciais IMAP funcionam (confirmadas por teste manual de nó).
Nenhum erro de validação de workflow bloqueia a ativação.
Não é um caso isolado: workflow completo duplicado, cópia ativada — mesmo resultado.
Múltiplas ativações/desativações (UI e API) não ajudaram.
forceReconnect aumentado do padrão de 60 para 180 minutos (mitigação de um thread comunitário similar) — nenhuma melhora até agora.
Qual é a mensagem de erro (se houver)?
Nenhuma — esse é exatamente o problema. Nem na interface, nem na lista de execuções, nem através de um workflow de erro aparece qualquer erro. O gatilho simplesmente não responde.
Compartilhe seu workflow
(De preferência, apenas marque os dois nós de gatilho e copie com Ctrl+C, não o workflow inteiro — contém dados/preços comerciais que não devem ser públicos. Clique em “IONOS Mailbox (IMAP Trigger)”, depois cole no campo de texto.)
Compartilhe a saída retornada pelo último nó
Não aplicável — nenhuma execução ocorre que pudesse produzir uma saída.
Informações sobre sua configuração n8n
Versão n8n: 2.35.4
Banco de dados (padrão: SQLite): n8n Cloud (gerenciado, não acessível)
Oi @wangii Bem-vindo!
Force Reconnect Every Minutes é o intervalo entre reconexões, então 180 deixa o nó com uma única conexão IMAP por três horas. IONOS para de enviar notificações de novo-email nessa conexão ociosa, o nó nunca fica sabendo que o email chegou, e nada chega à lista de execução, o que também é o motivo pelo qual o gatilho Telegram ao lado não é afetado. Defina para 5 e mude Format de Simple para Resolved no mesmo nó.
Veja isto:
Oi, obrigado pela explicação! Infelizmente isso não fez o trigger voltar a funcionar para nós: forceReconnect está agora há cerca de 19 horas em 5 minutos (o formato já era “Resolved”), o workflow está continuamente ativo. Nesse período, dois novos e-mails de teste chegaram, ambos continuam não lidos na caixa de entrada, nenhuma execução de workflow foi criada (nem mesmo uma com falha). Há algo mais que possamos verificar? Logs do lado do servidor seriam úteis, se isso for possível.
Essa é uma forma útil de se livrar deles: Foram 19 horas com forcereconnect em 5, e nenhuma execução aconteceu. Então não é a conexão ociosa. O surpreendente é que há dois gatilhos em andamento no mesmo fluxo de trabalho. Crie um novo fluxo de trabalho para o gatilho IMAP e ative-o. Se estiver lá, o problema é a combinação de coisas em vez de IMAP ou as credenciais, e você tem sua solução ao mesmo tempo.
Você não consegue acessar os logs da instância no n8n Cloud, essa rota é help@n8n.io. Envie a URL da instância, o ID do fluxo de trabalho e o carimbo de data/hora de um email de teste, e mencione que forceReconnect já está em 5 e Format é Resolved para que você não receba essas sugestões de volta.
Um adendo que talvez deixe o diagnóstico mais preciso: não acredito que o problema esteja na conexão IMAP em si, mas no próprio processo de ativação do n8n. No editor de workflow, a mensagem “Activating triggers — this can take a moment” fica permanentemente exibida (não apenas brevemente), mesmo muito tempo depois que o workflow já é considerado “published” de acordo com o histórico de versões e a API. Enquanto esse estado persiste, o botão “Execute workflow” continua clicável – e um clique manual nele realmente processa os e-mails corretamente. De acordo com minha expectativa, esse botão deveria estar desativado assim que o workflow estivesse realmente completamente ativo. Isso me indica que a ativação do trigger IMAP nunca é concluída corretamente internamente (fica presa), enquanto o trigger Telegram no mesmo workflow é finalizado imediatamente.
Esse é um ponto muito melhor, e muda com o que estamos lidando. Se você vir um banner que diz “Ativando gatilhos” e ele não desaparecer, significa que a ativação ficou presa no meio do caminho. Isso ocorre porque o Telegram se completa imediatamente, então o gatilho IMAP é o que está bloqueando. Funciona com tudo mais: as credenciais estão OK, a execução manual funciona, e nada chega à lista de execução porque o gatilho nunca termina o registro. Ainda vale a pena executar o teste de gatilho único. Isso ocorre porque se o banner desaparecer com apenas o nó IMAP no fluxo de trabalho, você o identificou como um dos dois gatilhos que se ativam juntos.
Coloque esse detalhe no ticket literalmente, banner nunca desaparece, API diz publicado, Executar fluxo de trabalho permanece clicável, execuções manuais funcionam. Isso é muito mais acionável do que “o gatilho não dispara” e é algo que eles podem comparar com os logs de ativação do lado deles.
Obrigado pela sugestão! Testei exatamente isso: criei um fluxo separado e mínimo com APENAS o gatilho IMAP (as mesmas credenciais IONOS, nada mais, nenhum gatilho do Telegram ao lado) e ativei.
Resultado: mesmo problema. Um e-mail de teste foi enviado, continua não lido na caixa de entrada, 0 execuções. Portanto, o problema não está na combinação de vários gatilhos no mesmo fluxo – o gatilho IMAP falha completamente mesmo isolado.
O resultado de single-trigger descarta a última coisa do seu lado, e agora está marcado como um bug confirmado, portanto nenhuma configuração trará o trigger de volta.
Até que a correção seja lançada, remova a caixa de correio da conexão IMAP persistente. Adicione uma regra de encaminhamento na caixa de correio IONOS para um endereço do Gmail e use o Gmail Trigger com Poll Times definido para cada minuto. Ele busca em um agendamento em vez de manter uma sessão IDLE aberta, e uma busca que não encontra nada não conta contra sua cota de execução.