O Que É um 429 Too Many Requests? Atingindo um Rate Limit
Um 429 Too Many Requests é o status HTTP que um servidor retorna quando um cliente enviou mais requisições do que o rate limit permite e precisa esperar antes de tentar novamente.
Ao contrário da maioria dos erros 4xx, um 429 não significa que sua requisição estava malformada; significa que você enviou muitas, rápido demais. Pipelines que se espalham por muitos jobs ou fazem polling agressivo de APIs atingem 429s com frequência. A resposta certa é fazer backoff e retry, idealmente guiado pelas dicas do servidor na resposta.
Um sinal de rate-limit
O servidor retorna 429 quando você excede sua taxa de requisições permitida para seu token, IP ou conta. É a forma explícita de uma API dizer "desacelere" em vez de falhar silenciosamente.
Leia os headers
- Retry-After indica quanto tempo esperar.
- Headers de rate-limit reportam a quota restante e o horário de reset.
- Honrar esses headers é a forma correta e educada de fazer backoff.
Por que o CI atinge 429s
Um matrix build, jobs paralelos compartilhando um token, ou um loop de polling apertado podem estourar uma quota rapidamente. Concentrar muitas chamadas em uma rajada curta é o culpado usual.
Fazendo backoff corretamente
Use backoff exponencial com jitter para que os retries se espalhem em vez de todos tentarem de novo ao mesmo tempo. Adicione cache e reduza chamadas desnecessárias para ficar abaixo do limite em primeiro lugar.
Passível de retry, com uma espera
Um 429 é um dos poucos códigos do lado do cliente que é feito para ter retry, mas apenas após o atraso indicado. Fazer retry imediatamente apenas rende outro 429 e pode estender a penalidade.
Backoff automático nos runners
Ferramentas robustas detectam 429s e fazem retry após honrar o Retry-After. Os runners da Latchkey fazem backoff e retry de 429s transitórios de endpoints comuns, para que um throttling breve não faça um job de outro modo saudável falhar.
Principais conclusões
- Um 429 significa que você excedeu um rate limit e deve esperar antes de fazer retry.
- Honre o Retry-After e os headers de rate-limit em vez de fazer retry imediatamente.
- Ele é passível de retry após um atraso, ao contrário da maioria dos outros erros 4xx.