O Que É uma Falha Transitória em CI? Explicação
Uma falha transitória é aquela causada por uma condição ambiental temporária: reexecute exatamente o mesmo job um instante depois e ele passa.
Nem todo build vermelho significa que seu código está quebrado. Uma grande parcela das falhas de CI vem do mundo ao redor do job, não do job em si: uma rede instável, um registry sobrecarregado, um runner que ficou brevemente sem memória. Essas falhas são transitórias, e a resposta certa é fundamentalmente diferente da de uma falha de código.
A propriedade que a define: passível de retry
Uma falha transitória é, por definição, aquela que um retry consegue resolver. As entradas eram válidas, o código estava correto, mas uma condição temporária no ambiente interferiu. Como nada no seu código ou configuração está errado, simplesmente executar o job de novo muitas vezes já é suficiente.
Origens típicas
- Instabilidades de rede: falhas de DNS, conexões derrubadas, timeouts de handshake TLS.
- Pressão a montante: rate limits de package-registry ou respostas 5xx.
- Esgotamento de recursos: um out-of-memory kill transitório ou uma condição de disco cheio.
- Infraestrutura: uma preempção de spot-instance ou um breve incidente do provedor.
Por que isso importa
Quando falhas transitórias são tratadas como falhas reais, cada uma delas custa a uma pessoa uma troca de contexto, uma investigação e um retry manual. Pior: elas treinam o time a reexecutar reflexivamente builds vermelhos, o que embota a resposta a falhas genuínas e determinísticas que de fato precisam de atenção.
Transitória vs determinística
Uma falha determinística acontece toda vez que você executa o job, porque a causa está no código ou na configuração. Uma falha transitória acontece às vezes, porque a causa está no ambiente. A pergunta diagnóstica mais útil de todas é: ela se reproduz de forma confiável? Se sim, é determinística e um retry não vai ajudar.
A perspectiva da Latchkey
Distinguir transitório de determinístico é exatamente o que os managed runners com autocorreção da Latchkey automatizam. Eles detectam falhas transitórias e mecânicas como instabilidades de rede, timeouts de registry e out-of-memory kills e automaticamente executam um retry do job afetado, de modo que uma instabilidade ambiental isolada não faça seu build falhar, enquanto falhas genuínas de código ainda aparecem como vermelho.
Principais conclusões
- Uma falha transitória é causada por uma condição ambiental temporária.
- Ela é passível de retry: o mesmo job passa quando executado de novo.
- As origens comuns são redes, registries, recursos e infraestrutura.
- Distinguir transitório de determinístico é a habilidade-chave de confiabilidade.