O Que É um Retry Automático? Explicação
Um retry automático reexecuta por conta própria uma operação que falhou, apostando que a falha foi temporária e que uma segunda tentativa vai passar.
Retries são a ferramenta mais simples e antiga para lidar com sistemas não confiáveis. Em CI, eles transformam uma classe de falhas de "humano investiga e reexecuta" em "o sistema resolve". Mas um retry só é uma boa ideia contra uma falha transitória, e aplicá-lo ao tipo errado de falha piora as coisas.
A ideia central
Quando uma operação falha, um retry automático simplesmente tenta de novo, até algum limite. A suposição implícita é que a falha foi transitória: uma condição temporária se resolveu e as mesmas entradas agora vão produzir sucesso. Para falhas genuinamente transitórias, isso é enormemente eficaz e custa apenas um pouco de tempo a mais.
Quando um retry ajuda
Retries ajudam quando a falha é ambiental e se resolve sozinha: uma conexão derrubada, um registry retornando 503, uma breve condição de out-of-memory em um runner ocupado. A operação era válida; o mundo apenas atrapalhou por um momento.
Quando um retry prejudica
Fazer retry de uma falha determinística é um erro. Uma assertion que falha, um erro de compilação ou uma variável de ambiente ausente vão falhar de forma idêntica em cada tentativa, então retries só queimam minutos e adiam o vermelho inevitável. Fazer retry de efeitos colaterais não idempotentes (um deploy que passou pela metade) também pode ser ativamente perigoso.
Tornando retries seguros
- Limite o número de tentativas para que uma falha definitiva não entre em loop para sempre.
- Adicione backoff (idealmente com jitter) para que os retries não martelem um upstream em dificuldades.
- Restrinja retries a classes de erro transitórias, não a toda falha.
- Garanta que a operação reexecutada seja idempotente, para que uma primeira tentativa parcial seja segura.
A perspectiva da Latchkey
Os managed runners com autocorreção da Latchkey aplicam retries automáticos de forma seletiva: eles fazem retry de jobs que falham em problemas transitórios e mecânicos detectados, como instabilidades de rede e out-of-memory kills, de modo que uma instabilidade isolada não faça seu build falhar, enquanto deixam falhas determinísticas de código falharem rápido, como devem.
Principais conclusões
- Um retry automático reexecuta uma operação que falhou sem um humano.
- Ele ajuda em falhas transitórias e prejudica nas determinísticas.
- Limite as tentativas e adicione backoff para não martelar os upstreams.
- Faça retry apenas de operações idempotentes para evitar efeitos colaterais parciais.