Navegue neste artigo
Um evento de pedido chega, a mensagem é enviada e a conexão cai antes da confirmação. Reexecutar tudo parece uma solução, mas pode enviar a mensagem duas vezes. Vamos separar falha de comunicação de falha da ação.
Defina entrada, efeito e responsável
Antes de montar os nodes, descreva o evento que inicia o fluxo, os campos obrigatórios e o efeito esperado. Use um identificador estável do evento de negócio. Uma nova execução no n8n não significa necessariamente um novo pedido.
Valide o payload e as credenciais de origem antes de chamar serviços externos. Use credenciais com o menor acesso necessário e um destino de teste para os exercícios.
evento: order_42_paid
ação: notificar_cliente
chave: order_42_paid:notificar_cliente
resultado esperado: uma notificação confirmada
se ambíguo: reconciliar antes de tentar novamenteUma tentativa nova não deve criar uma ação nova
Idempotência significa que repetir a mesma operação não deve produzir efeitos adicionais indevidos. Se o provedor aceita uma chave de idempotência, reutilize-a nas tentativas. Não gere uma chave diferente a cada execução.
Sem suporte do provedor, registre a intenção com uma restrição única e acompanhe seu estado. Se a conexão cair depois do envio, marque o resultado como desconhecido e consulte ou reconcilie o destino. Só gravar ‘enviado’ antes da chamada pode perder uma entrega; só gravar depois pode duplicá-la.
O n8n orquestra o fluxo. A garantia contra duplicações depende também do armazenamento e do comportamento do sistema de destino.
Escolha quais falhas podem ser repetidas
Uma indisponibilidade temporária pode justificar nova tentativa com espera e limite. Uma credencial inválida ou um payload rejeitado normalmente exige correção. Repetir sem distinguir os casos transforma um erro pequeno em uma fila de tentativas.
Configure um Error Workflow para encaminhar falhas ao responsável. Inclua identificação da execução, etapa e contexto mínimo para investigar. Evite anexar dados pessoais ou segredos ao alerta. Quando uma regra de negócio impedir continuar, o node Stop And Error pode sinalizar explicitamente a falha.
- Defina um limite de tentativas e uma condição de parada.
- Não ignore um erro e apresente sucesso ao usuário.
- Registre estados pendente, confirmado, falhou e desconhecido quando fizerem sentido.
- Documente quem reconcilia os casos sem resultado confirmado.
Teste quatro situações antes de ativar
Em um ambiente de teste, envie um evento válido; depois repita o mesmo evento. Em seguida, simule indisponibilidade antes da chamada e perda de resposta após a ação. Verifique o estado no destino, não apenas se a execução ficou verde.
O exercício termina quando você consegue explicar o resultado dos quatro cenários, identificar quem recebe o alerta e reprocessar sem efeito duplicado. Guarde esses casos para repetir quando o workflow ou a integração mudar.
- Entrada válida: uma ação confirmada.
- Evento duplicado: nenhum efeito adicional.
- Falha antes do envio: tentativa limitada ou encaminhamento.
- Resposta perdida: reconciliação antes de uma nova ação.
Não use pagamentos, disparos em massa ou clientes reais para testar esses cenários.
Fontes e leituras relacionadas
Material educativo. Valide os exemplos em um ambiente de teste e adapte as decisões ao contexto, aos riscos e às responsabilidades do seu projeto.
Compartilhar