O Que É um Dead-Letter (Job com Falha)? Explicado
Um dead-letter é o local de retenção para trabalho que falhou tantas vezes que o sistema desiste de fazer retry dele e o coloca de lado para atenção humana.
Retries não podem ter sucesso para sempre; em algum momento um sistema precisa parar e admitir a derrota para um determinado item. O padrão dead-letter, vindo das filas de mensagens, captura isso: após esgotar os retries, o item com falha é movido para uma dead-letter queue para que não seja perdido e não bloqueie tudo o que está atrás dele.
O padrão
Um worker tenta processar uma mensagem. Se ela continua falhando além de um limite de retry, em vez de fazer retry infinitamente (o que bloquearia a fila) ou descartá-la (o que perderia dados), o sistema a roteia para uma dead-letter queue. Ali ela aguarda inspeção, enquanto o processamento normal continua sem obstrução.
Por que ele existe
Sem um destino dead-letter, um único item envenenado, um que sempre falha, ou trava a fila para sempre ou desaparece silenciosamente. A dead-letter queue é a válvula de segurança: ela isola as falhas para que sejam visíveis e recuperáveis sem segurar o trabalho saudável.
A analogia com o CI
Em um pipeline com autocorreção, a mesma lógica se aplica. Um job que falha transitoriamente recebe retry; mas um job que continua falhando além do orçamento de retry não deve receber retry para sempre. É o caso dead-letter: parar de fazer retry, marcá-lo como uma falha genuína e trazê-lo à atenção de um humano, porque mais retries não ajudarão.
O que fazer com trabalho em dead-letter
- Inspecione-o para encontrar a causa real e persistente.
- Distinga um item envenenado (nunca terá sucesso) de uma interrupção longa.
- Corrija a causa raiz e, então, opcionalmente reexecute-o ou faça replay.
- Alerte sobre o volume de dead-letter para que falhas silenciosas não se acumulem.
O ângulo da Latchkey
Retries limitados são centrais para uma autocorreção honesta. Os runners gerenciados com autocorreção da Latchkey fazem retry de falhas transitórias e mecânicas para que um piscar isolado não faça seu build falhar, mas não fazem retry para sempre: um job que continua falhando além do seu limite emerge como uma falha real em vez de entrar em laço silenciosamente.
Principais conclusões
- Um dead-letter retém trabalho que falhou vezes demais para continuar fazendo retry.
- Ele evita que um item envenenado trave a fila ou seja silenciosamente perdido.
- Em CI, é o caso em que os retries se esgotam e um humano é necessário.
- Uma autocorreção honesta tem limites de retry, não retries infinitos.