Estou enfrentando um problema onde um workflow com um nó Email Trigger (IMAP) se desativa imediatamente quando tento ativá-lo, lançando um WorkflowActivationError que é capturado pelo Error Trigger do workflow.
Porém, a execução manual funciona perfeitamente sem nenhum erro.
Detalhes do erro (capturado pelo Error Trigger):
[
{
"trigger": {
"error": {
"message": "There was a problem with the trigger node \"Email Trigger (IMAP)\", for that reason did the workflow had to be deactivated",
"timestamp": 1785767782822,
"name": "WorkflowActivationError",
"context": {}
},
"mode": "trigger"
},
"workflow": {
"id": "zTAdqKiYBPODh3yr",
"name": "03.03. Яндекс -> amoCRM (deleted@pioneercert.ru)"
}
}
]
Oi @Sokol
WorkflowActivationError é o wrapper que o n8n passa para o Error Trigger quando um nó de trigger falha, e os erros de nós de trigger sempre chegam com context: {} e sem causa, então a falha real do IMAP nunca atinge a UI e vai para o log da instância. Execuções manuais fazem um único fetch e fecham, a ativação mantém a conexão aberta, por isso apenas a ativação dispara. Ative o workflow e leia o log logo após:
A linha começando com “Email Read Imap:” carrega a razão real, geralmente uma conexão fechada inesperadamente, uma rejeição de autenticação do servidor, ou um erro de caixa de correio, e isso define a solução. No Cloud esses logs não são acessíveis do seu lado, help@n8n.io pode extraí-los para o workflow zTAdqKiYBPODh3yr.
O detalhe faltante na carga de erro é rastreado aqui:
Oi,
Ainda na versão 2.33.3, mesmo padrão ECONNRESET/EPIPE de antes da atualização, nenhuma mudança.
Uma coisa que notei é que não está isolado em uma única caixa de correio, mail@, deleted@ e notification@ no mesmo VPS estão caindo ao mesmo tempo, no mesmo sistema de loop apertado. Isso me fez pensar se isso é realmente algo da camada de rede e não algo que o Yandex ou n8n está fazendo por conta. Como o firewall do VPS ou a tabela conntrack matando conexões ociosas antes do n8n ter a chance de reconectar.
Ainda não verifiquei o timeout de conntrack, vou executar
sysctl net.netfilter.nf-conntrack-tcp-timeout-established e postar o valor. Também vou verificar qual é a configuração atual de Force Reconnect nesses nós, pois não tenho certeza se está nem configurado.
Por que a configuração de 15 minutos não corresponde ao que vi no log?
Agradeço por compartilhá-lo. Um item se destaca: embora Force Reconnect esteja definido para 15 minutos, os problemas ECONNRESET/EPIPE estavam ocorrendo sequencialmente em um loop apertado em vez de aproximadamente a cada 15 minutos, de acordo com o log que você forneceu anteriormente. Você esperaria falhas espalhadas por cerca de 15 minutos de intervalo em vez de um pico repentino se Force Reconnect fosse o responsável. Portanto, essa opção provavelmente não é a razão principal; a conexão está sendo encerrada muito antes dos 15 minutos permitidos passarem.
Vale a pena verificar se os valores das outras caixas de correio (mail@, notification@) são iguais ou se uma está definida de forma diferente ou não definida. Isso tornaria mais fácil determinar se é configuração por nó ou algo que as afeta igualmente.
Ainda planejando verificar o timeout de conntrack, vou postar esse valor assim que o tiver — essa é a informação que realmente nos dirá se é a VPS/firewall ou algo no tratamento de reconexão do n8n.
Se precisar de dados adicionais ou se enviei algo errado, por favor me avise. Vou enviar as informações adicionais para que a gente consiga encontrar uma solução.
execute docker logs n8n-n8n-worker-1 2>&1 | grep -i imap e veja o que aparece. Forneça-me os resultados.
Também qual EXECUTIONS_MODE está configurado (ou se você está usando N8N_DISABLE_PRODUCTION_MAIN_PROCESS).
Também forneça a saída do log do worker a partir da mesma janela de tempo de uma das falhas em sua captura de tela docker ps/log, para que os registros de data e hora possam ser realmente alinhados com as falhas do processo principal.
se esse erro de LOGIN aparece repetidamente em diferentes caixas de correio, e se os timestamps se agrupam próximos uns dos outros porque se várias caixas de correio no mesmo domínio/IP estão todas tentando fazer LOGIN nos mesmos momentos, isso parece ser o sistema anti-abuso/limite de taxa do Yandex acionado por tentativas de login repetidas vindas de um IP de VPS, não um problema por conta.
Minha sugestão:
esse código sc= é um identificador de rastreamento/suporte do lado do Yandex, vale a pena você levá-lo diretamente ao suporte do Yandex, porque se for limite de taxa, não é algo que possa ser corrigido puramente pelo lado da configuração do n8n.
@Sokol a chamada que falha é LOGIN, não o socket. “LOGIN internal server error sc=…_imap-production-main-623” é Yandex recusando a sessão, e os pares ECONNRESET e EPIPE são essas sessões sendo fechadas logo depois. Nenhuma mudança de configuração do n8n muda isso, a correção está no lado da caixa de correio.
Para cada um dos deleted@, mail@ e notification@:
Faça login nessa caixa de correio uma vez em mail.yandex.com. O Acordo do Usuário é aceito no primeiro login na web, por caixa de correio, e caixas de correio de serviço geralmente nunca foram acessadas.
Em Configurações > Clientes de email, confirme que “Do servidor imap.yandex.com via IMAP” está ativo e o método de autorização está configurado para senhas de aplicativo.
Gere uma senha de aplicativo para essa caixa de correio no Yandex ID e use-a na credencial IMAP do n8n em vez da senha da conta.
Yandex também bloqueia caixas de correio que seu sistema de segurança marca como suspeitas, geralmente as sem nome real ou telefone vinculado, e esse bloqueio se libera automaticamente após algumas horas, o que corresponde a erros que vão e vêm enquanto execuções manuais ainda funcionam. Troubleshooting email client issues | Yandex Mail
