Workflows com retry e observabilidade

Um job simples roda e acaba. A vida real é mais bagunçada: a API de terceiro cai, a rede oscila, o modelo de IA demora. A diferença entre um job de brinquedo e um de produção está em como ele lida com o erro — e em você enxergar o que aconteceu. Esse é o tema deste post.

Por que retry não é opcional

Tudo que depende de rede falha às vezes. Chamar a Evolution API, o Claude, o Resend, uma API de terceiro — qualquer uma pode dar timeout num dia ruim. Sem retry, uma falha boba mata o job inteiro e o resumo não chega. Com retry, o job tenta de novo e o usuário nem percebe que houve soluço.

O Trigger.dev dá retry com política configurável (quantas vezes, com que intervalo, backoff). Você decide o quão teimoso o job deve ser.

Mas retry exige idempotência

Lembra do #25? Retry e idempotência são inseparáveis. Se o job falhou depois de já ter gravado metade, o retry precisa não duplicar a metade que deu certo. Retry sem idempotência transforma uma falha em dois problemas.

Observabilidade: enxergar o invisível

Job roda sozinho, escondido. Sem observabilidade, você só descobre que quebrou quando alguém reclama que "o resumo não chegou". O Trigger.dev dá log e status por execução — então você consegue:

• Ver o que rodou, quando e quanto demorou.
• Achar a execução que falhou e por quê.
• Distinguir "falhou e o retry salvou" de "falhou de vez".

A camada de bom senso: alertar quando importa

Observabilidade é poder olhar. O passo seguinte é ser avisado quando algo crítico falha de vez, em vez de depender de ir olhar. Job silencioso que falha em silêncio é o pior dos mundos.

Vibe coding aqui

A IA configura retry e estrutura o workflow bem. O julgamento humano: quantas tentativas fazem sentido (teimar demais numa API fora do ar só atrasa), o que é falha tolerável vs. crítica, e garantir que o retry é seguro. É Lealdade a Dados aplicada à operação: você decide com base no que o log mostra, não no que você imagina que acontece.

⚠️ Armadilha #26: configurar retry agressivo num job não-idempotente. Você não tornou o job resiliente — tornou cada falha um multiplicador de dado duplicado.

Próximo da série: #27 — IA em background: resumos e narrativas.