Oi a todos!
Estou continuamente aprendendo n8n e tentando melhorar minhas habilidades de construção de fluxos de trabalho.
Quero entender como desenvolvedores de automação experientes lidam com erros em fluxos de trabalho do mundo real.
Algumas perguntas:
Quando uma solicitação de API falha, como você a retenta automaticamente?
Como você usa o nó Error Trigger em fluxos de trabalho em produção?
Como você evita dados duplicados quando um fluxo de trabalho é executado novamente após uma falha?
Qual é sua abordagem para registrar erros e notificar clientes?
Gostaria de ouvir como você lida com gerenciamento de erros em seus projetos n8n do mundo real.
Estou aqui para aprender com a comunidade e melhorar minhas habilidades de automação.
Obrigado antecipadamente!
Ei @abid_zia, enquanto espera por uma resposta, aqui estão algumas coisas que podem ajudar:
Recursos sugeridos
Automaticamente correspondido à sua pergunta.
Documentação:
Fórum:
@Niffzy - você já ajudou com problemas semelhantes antes, pode dar uma olhada?
Sugerido automaticamente pelo bot comunitário do n8n. É um piloto - compartilhe seu feedback aqui.
Oi @abid_zia, eu começaria com um fluxo de erro compartilhado e tornaria cada escrita segura para repetir.
-
Tentativas: Abra as Configurações → Repetir se Falhar do nó da API, limite as tentativas e defina Aguardar Entre Tentativas (ms). Use isso para falhas temporárias em requisições que são seguras para repetir.
-
Gatilho de Erro: Crie e publique
Gatilho de Erro → log → Slack/email, depois selecione-o nas Configurações → Fluxo de trabalho de erro do fluxo de trabalho principal. Teste com um gatilho automático e Parar e Erro; execuções no editor manual não acionam o fluxo de trabalho de erro. -
Duplicatas: Para registros de banco de dados, use o ID do evento/pedido de origem como chave única e use upsert em vez de inserir novamente. Para gravações de API, reutilize a mesma chave de idempotência imposta pelo provedor para cada ação lógica entre tentativas e reexecuções. Um tempo limite pode ocorrer após a gravação ser bem-sucedida, portanto, resultados incertos precisam de reconciliação se a API não tiver suporte a idempotência.
-
Registro e clientes: Registre o nome do fluxo de trabalho, nó com falha, mensagem de erro, carimbo de data/hora e link de execução quando disponível. Alerte internamente após as tentativas se esgotarem; envie ao cliente uma mensagem curta de impacto/status quando o trabalho dele for afetado.
Um padrão seguro de email/CRM é manter um registro durável com chave do ID do evento de origem com estados enfileirado → enviando → enviado, mais desconhecido para um timeout após uma possível escrita remota. Na repetição, reproduza apenas itens enfileirados; reconcilie desconhecidos contra o provedor/CRM ou encaminhe para uma pessoa. Isso evita tratar uma execução vermelha como prova de que nada aconteceu. Teste com um timeout após o provedor aceitar um email, depois execute a recuperação duas vezes; nenhuma recuperação deve criar um segundo envio.
Uma coisa que vale a pena adicionar é separar falhas esperadas das inesperadas. No nó HTTP Request, defina On Error como „Continue (using error output)
Como o thread apenas tem o cabeçalho truncado, não consigo ver quais abordagens já foram sugeridas, então vou manter isso geral. Para falhas de workflow, a linha de base útil é um workflow de erro definido nas configurações do workflow, que captura erros de nó não tratados e fornece o ID de execução e o nó que falhou. A partir daí, registrar falhas em algum lugar durável (um banco de dados ou planilha) ajuda a identificar padrões em vez de reagir a alertas isolados. Nas tentativas, cuidado com nós que não são idempotentes, já que uma tentativa pode criar duplicatas. Que tipo de falhas você está enfrentando na maioria das vezes, timeouts, autenticação ou problemas de formato de dados?
Ative Tentar Novamente ao Falhar nas configurações do nó HTTP, com uma espera entre as tentativas. Coloque um Gatilho de Erro em seu próprio fluxo de trabalho que envie uma mensagem no Slack ou por email com o nome do fluxo de trabalho e o link de execução. Para duplicatas, use um upsert em um ID único em vez de um simples create, para que uma reexecução apenas sobrescreva o mesmo registro.
Duas coisas em que confio em fluxos de trabalho de clientes que ninguém mencionou ainda.
Primeiro, execuções em lote. Quando um fluxo de trabalho processa muitos itens, um registro ruim não deve derrotar toda a execução. Configure o nó que acessa a API para Continuar usando saída de erro, crie uma ramificação logo após ele e reúna os maus registros em uma lista separada de itens com falha que você registra no final. Você termina corrigindo 3 registros em vez de re-executar 500.
Segundo, quando uma execução morre no meio do caminho, não a reconstrua. Ative Salvar progresso da execução nas configurações do fluxo de trabalho, abra a execução com falha e clique em Repetir. Ele retoma do nó que falhou em vez de começar do zero, o que importa quando os primeiros 20 nós demoraram 10 minutos. Uma ressalva: se algum nó anterior tiver efeitos colaterais como enviar e-mails, uma repetição completa dispará aqueles novamente, então mantenha os nós com efeitos colaterais protegidos com uma verificação se o trabalho já aconteceu.
E teste o branch de erro propositalmente. Alimente o nó com um falso 500 e um payload malformado e observe o que realmente acontece. Retry On Fail (Repetir Se Falhar) ficará feliz em repetir uma solicitação que nunca poderá ter sucesso.
Bom conselho acima. Uma coisa que eu adicionaria: verifique se o próprio tratamento de erros funciona e procure por falhas que nunca geram um erro.
Duas coisas que me pegaram em uma instância de produção:
- Um fluxo de trabalho de erro pode ser definido em Configurações e ainda estar inativo. Encontrei um apontando para si mesmo, um apontando para um fluxo de trabalho que nunca foi publicado e um bloqueado pela configuração “Este fluxo de trabalho pode ser chamado por” do alvo. n8n aceita os três. Então execute o teste que Anshul descreve em cada fluxo de trabalho, não apenas no primeiro.
- Um agendamento que para de disparar não produz erro, então nenhum Error Trigger vai te avisar. O mesmo vale para uma falha capturada por um ramo de erro: a execução ainda termina como sucesso. Você só consegue detectar isso de fora, comparando quando cada agendamento deveria ter executado com as execuções que existem.
Construí uma pequena verificação diária para esses casos e a publiquei como um modelo gratuito, caso seja útil: Send daily workflow health digests with the n8n API and Gmail | n8n workflow template