O que é Retry?

O que é retry

Retry é uma nova tentativa de executar uma ação depois de uma falha ou de um resultado que o cliente não conseguiu confirmar. Ele pode recuperar uma consulta interrompida por uma indisponibilidade breve, desde que o serviço volte a responder e a chamada continue válida.

A repetição também pode acontecer depois de um timeout, quando a espera termina sem confirmar o resultado no destino. Nessa situação, você precisa considerar que a ação pode ter sido concluída, mesmo que a aplicação tenha recebido um erro local.

O motivo da falha orienta a repetição

Uma interrupção de rede pode desaparecer na próxima tentativa, enquanto uma chamada sem um campo obrigatório continuará incompleta. O retry deve seguir os erros recuperáveis documentados e o comportamento da ação, sem tratar toda resposta de falha da mesma maneira.

Uma credencial expirada pode exigir renovação antes de repetir, e uma recusa por excesso de chamadas pode exigir espera. O tratamento precisa realizar essa correção ou respeitar o intervalo, em vez de reenviar o mesmo conteúdo continuamente.

Quantidade, intervalo e duração total

A política precisa definir quantas tentativas serão permitidas e quanto tempo esperar entre elas. O backoff controla as pausas, enquanto um prazo total pode impedir que uma tarefa permaneça tentando além do tempo útil para o processo.

Confira se a configuração inclui a chamada inicial no total. Três tentativas e três repetições depois da primeira chamada representam quantidades diferentes de acesso ao serviço e de tempo potencial de espera.

Retries em várias camadas também podem se multiplicar. Em um exemplo com três tentativas no workflow e três tentativas internas na biblioteca a cada chamada, o destino pode receber até nove chamadas para a mesma ação.

A ação anterior pode ter produzido efeito

Uma falha de comunicação não equivale à confirmação de que nada aconteceu. O servidor pode ter criado um registro e perdido a conexão antes de devolver seu identificador, deixando o cliente sem o resultado.

Nessa situação, repetir uma criação sem proteção pode gerar outro registro. A idempotência e a consulta do estado no destino permitem planejar a recuperação conforme as garantias disponíveis, incluindo a reutilização da mesma chave quando a API oferecer esse mecanismo.

Também considere os efeitos anteriores de um workflow. Se a falha aconteceu no envio da confirmação, repetir o fluxo inteiro pode refazer um cadastro que já terminou, embora apenas o envio ainda esteja pendente.

O mesmo erro pode continuar sendo temporário

Receber a mesma falha em todas as tentativas não demonstra, sozinho, que ela é permanente. Uma indisponibilidade de alguns minutos pode ultrapassar uma política de recuperação curta e produzir respostas iguais durante todo o intervalo observado.

O limite encerra a tentativa automática para aquele processamento, sem diagnosticar por si só a causa. Preserve o erro e o identificador da tarefa para permitir investigação e recuperação depois, conforme o processo previsto.

Como testar a recuperação

Simule uma falha antes da ação e outra depois do efeito, mas antes da confirmação ao cliente. Observe a quantidade de chamadas, os intervalos e o resultado final no destino.

Inclua também uma entrada inválida que não deve ser repetida automaticamente. O teste precisa mostrar que a automação recupera falhas previstas sem consumir todas as tentativas em uma chamada que ainda exige correção.

Aplicação na formação

n8n Experts

O retry repete uma tentativa conforme condições e limites definidos, considerando possíveis efeitos duplicados.

Conhecer a formação →