Fluxo de trabalho com Gmail Trigger não funcionando e muito lento para publicar
Qual é a mensagem de erro (se houver)?
O Gmail Trigger não funciona de forma confiável. Consegui fazê-lo funcionar algumas vezes, mas na maioria das vezes ele simplesmente não reage a novas mensagens. No computador onde estou executando o n8n auto-hospedado, vejo os seguintes erros. Esta é uma máquina com conexões de saída muito limitadas, mas consegui fazê-la funcionar em algum momento, portanto não acho que esse deva ser o problema.
Aug 01 10:20:33 orejon.ll.iac.es n8n[1375]: at AxiosError.from (/home/angelv-adm/.npm-global/lib/node_modules/n8n/node_modules/axios/dist/node/axios.cjs:1355:24)
Aug 01 10:20:33 orejon.ll.iac.es n8n[1375]: at RedirectableRequest.handleRequestError (/home/angelv-adm/.npm-global/lib/node_modules/n8n/node_modules/axios/dist/node/axios.cjs:4026:25)
Aug 01 10:20:33 orejon.ll.iac.es n8n[1375]: at RedirectableRequest.emit (node:events:520:35)
Aug 01 10:20:33 orejon.ll.iac.es n8n[1375]: at ClientRequest.eventHandlers. (/home/angelv-adm/.npm-global/lib/node_modules/n8n/node_modules/follow-redirects/index.js:56:24)
Aug 01 10:20:33 orejon.ll.iac.es n8n[1375]: at ClientRequest.emit (node:events:508:28)
Aug 01 10:20:33 orejon.ll.iac.es n8n[1375]: at emitErrorEvent (node:_http_client:108:11)
Aug 01 10:20:33 orejon.ll.iac.es n8n[1375]: at TLSSocket.socketErrorListener (node:_http_client:575:5)
Aug 01 10:20:33 orejon.ll.iac.es n8n[1375]: at TLSSocket.emit (node:events:520:35)
Aug 01 10:20:33 orejon.ll.iac.es n8n[1375]: at emitErrorNT (node:internal/streams/destroy:170:8)
Aug 01 10:20:33 orejon.ll.iac.es n8n[1375]: at emitErrorCloseNT (node:internal/streams/destroy:129:3)
Aug 01 10:20:33 orejon.ll.iac.es n8n[1375]: at Axios.request (/home/angelv-adm/.npm-global/lib/node_modules/n8n/node_modules/axios/dist/node/axios.cjs:5427:41)
Aug 01 10:20:33 orejon.ll.iac.es n8n[1375]: at processTicksAndRejections (node:internal/process/task_queues:104:5)
Aug 01 10:20:33 orejon.ll.iac.es n8n[1375]: at invokeAxios (/home/angelv-adm/.npm-global/lib/node_modules/n8n/node_modules/@n8n/backend-network/src/http/axios/invoke.ts:15:10)
Aug 01 10:20:33 orejon.ll.iac.es n8n[1375]: at httpRequest (/home/angelv-adm/.npm-global/lib/node_modules/n8n/node_modules/@n8n/backend-network/src/http/axios/request.ts:211:5)
Aug 01 10:20:33 orejon.ll.iac.es n8n[1375]: at Object.request (/home/angelv-adm/.npm-global/lib/node_modules/n8n/node_modules/@n8n/backend-network/src/http/outbound-http.ts:188:12)
Aug 01 10:20:33 orejon.ll.iac.es n8n[1375]: at paginatedRequest (/home/angelv-adm/.npm-global/lib/node_modules/n8n/src/utils/strapi-utils.ts:87:15)
Aug 01 10:20:33 orejon.ll.iac.es n8n[1375]: at getCommunityNodeTypes (/home/angelv-adm/.npm-global/lib/node_modules/n8n/src/modules/community-packages/community-node-types-utils.ts:54:9)
Aug 01 10:20:33 orejon.ll.iac.es n8n[1375]: at CommunityNodeTypesService.fetchNodeTypes (/home/angelv-adm/.npm-global/lib/node_modules/n8n/src/modules/community-packages/community-node-types.service.ts:93:13)
Aug 01 10:20:33 orejon.ll.iac.es n8n[1375]: at CommunityNodeTypesService.getCommunityNodeTypes (/home/angelv-adm/.npm-global/lib/node_modules/n8n/src/modules/community-packages/community-node-types.service.ts:213:4)
Aug 01 10:20:33 orejon.ll.iac.es n8n[1375]: at CommunityNodeTypesController.getCommunityNodeTypes (/home/angelv-adm/.npm-global/lib/node_modules/n8n/src/modules/community-packages/community-node-types.controller.ts:18:10)
Aug 01 10:20:33 orejon.ll.iac.es n8n[1375]: read ECONNRESET
Aug 01 10:20:33 orejon.ll.iac.es n8n[1375]: Error: read ECONNRESET
Aug 01 10:20:33 orejon.ll.iac.es n8n[1375]: at TLSWrap.onStreamRead (node:internal/stream_base_commons:216:20)
Aug 01 10:20:33 orejon.ll.iac.es n8n[1375]: Error fetching from Strapi API (https://api-staging.n8n.io/api/community-nodes): read ECONNRESET
Aug 01 10:22:51 orejon.ll.iac.es n8n[1375]: There was a problem in ‘Gmail Trigger’ node in workflow ‘7’: ‘undefined’
Por favor, compartilhe seu fluxo de trabalho
Compartilhe a saída retornada pelo último nó
Informações sobre sua configuração n8n
Versão n8n: 2.32.5
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): npm
Oi @angelv
Esses rastreamentos ECONNRESET são o n8n buscando a lista de nós da comunidade de api-staging.n8n.io, não do Gmail. “undefined” na linha do Gmail Trigger significa que a chamada da pesquisa para o Google falhou no nível do soquete, então não havia corpo de resposta da API para extrair uma mensagem, e uma pesquisa com falha é ignorada sem tentativa de retorno, é por isso que minutos inteiros de e-mail nunca chegam. Abra o 443 de saída para www.googleapis.com e oauth2.googleapis.com desse host. Teste no próprio box:
401 é o resultado saudável, significa que o host está acessível e apenas o token está faltando. Um erro de conexão ou um travamento significa que o filtro de saída está cortando.
Para a publicação lenta, isso impede que o n8n busque nós da comunidade a cada carregamento do editor:
Embora você tenha mencionado conexões de saída limitadas, o erro específico connect ETIMEDOUT 2001:4860:4840:400::443 revela que o n8n está tentando se conectar ao Google via IPv6, e sua rede/máquina não está configurada para IPv6 ou o firewall de saída está descartando pacotes IPv6.
Os erros ECONNRESET nos seus logs relacionados a api-staging.n8n.io confirmam ainda mais que sua máquina está tendo dificuldades com conexões TLS de saída estáveis para APIs externas.
Como sua máquina tem conectividade de saída limitada e está falhando em um endereço IPv6, você precisa forçar o Node.js (e assim o n8n) a preferir IPv4.
Adicione a seguinte variável de ambiente à sua configuração de inicialização do n8n (onde você define N8N_HOST, etc.):
Se você está usando um arquivo de serviço systemd (o que parece ser o caso baseado nos seus trechos de Environment=):
Edite o arquivo de serviço: sudo nano /etc/systemd/system/n8n.service (ou seu nome de arquivo específico).
Adicione a linha: Environment=NODE_OPTIONS=--dns-result-order=ipv4first.
Recarregue o systemd: sudo systemctl daemon-reload.
Reinicie o n8n: sudo systemctl restart n8n.
Para confirmar que a correção está funcionando fora do n8n, execute este comando do seu terminal:
# Forçar curl IPv4 para a API do Google
curl -4 -v https://www.googleapis.com/gmail/v1/users/me/profile
Se isso retornar 401 (Não Autorizado): O caminho de rede está aberto (401 é esperado porque você não está passando um token).
Se isso ainda expirar: Seu firewall de saída está bloqueando a porta 443 para os intervalos de IP do Google completamente, e você deve solicitar ao administrador de rede que coloque na whitelist *.googleapis.com.
Para outros erros de log
Error fetching from Strapi API... ECONNRESET: Isso é o n8n tentando verificar atualizações de nós comunitários. Não está relacionado ao seu fluxo de trabalho do Gmail, mas confirma a instabilidade geral de suas conexões de saída. Você pode ignorar isso ou desabilitar verificações de nós comunitários se possível.
There was a problem in 'Gmail Trigger'... 'undefined': Este é um travamento genérico resultante do ETIMEDOUT mencionado em sua captura de tela. Após aplicar a correção IPv4, isso deve desaparecer.
Não, aquele não está relacionado a Execute Command. N8N_COMMUNITY_PACKAGES_ENABLED apenas governa pacotes de nós da comunidade npm, aqueles instalados na página de configurações de nós da comunidade. Execute Command é um nó principal integrado e é controlado separadamente por NODES_EXCLUDE, que você já definiu como um array vazio, então ele continua carregando de qualquer forma.
O diagnóstico IPv4 parece estar correto — mas verifique ONDE você definiu NODE_OPTIONS. Se o n8n for executado sob systemd, exportá-lo no seu shell ou .bashrc nunca alcançará o serviço. Precisa estar como Environment=NODE_OPTIONS=–dns-result-order=ipv4first no arquivo da unidade (ou em um EnvironmentFile), depois systemctl daemon-reload e reiniciar.
Confirme se realmente foi aplicado em vez de apenas assumir: sudo strings /proc/$(pgrep -f n8n | head -1)/environ | grep NODE_OPTIONS. Se não aparecer nessa saída, a configuração nunca foi aplicada, e é por isso que nada mudou.
