O Que É um Erro de Rate Limit? Explicação
Um erro de rate limit significa que um serviço está deliberadamente rejeitando suas requisições porque você excedeu o número que ele permite em uma janela, comumente retornado como HTTP 429.
Para se protegerem, serviços limitam quantas requisições um cliente pode fazer por unidade de tempo. Quando a CI excede esse limite, muitas vezes durante uma rajada de instalações de pacotes ou pulls de imagem, o serviço responde com um erro de rate limit em vez de atender à requisição. É uma condição transitória que se resolve à medida que a janela reinicia.
O que é rate limiting
Um rate limit é uma política que permite apenas um determinado número de requisições em um período (por minuto, por hora) de um dado cliente ou IP. Quando você cruza o limiar, o serviço recusa novas requisições até a janela reiniciar, tipicamente com o status 429 Too Many Requests, às vezes 403.
Por que a CI o dispara
- Muitos jobs paralelos puxando as mesmas imagens ou pacotes de um único IP compartilhado.
- Requisições não autenticadas a registries, que costumam ter limites mais rígidos.
- Uma rajada de chamadas de API (atualizações de status, comentários) em um loop apertado.
- Retries sem backoff acumulando mais requisições durante uma janela limitada.
Como ler a resposta
Respostas de rate limit muitas vezes incluem um header Retry-After ou headers de cota restante dizendo quando você pode tentar de novo. Respeitá-los é o comportamento correto: espere o tempo indicado em vez de fazer retry imediato e aprofundar o problema.
Transitório, com uma ressalva
Um erro de rate limit é transitório porque a janela reinicia, então um retry após uma espera geralmente passa. Mas o retry certo é com backoff e ciente do Retry-After; fazer retry instantâneo apenas consome a próxima janela. Autenticar e usar cache reduzem a frequência com que você atinge limites de todo modo.
A perspectiva da Latchkey
Os managed runners com autocorreção da Latchkey tratam erros de rate limit como 429s de registry como transitórios e fazem retry com backoff sensato, de modo que um rate limit isolado durante um build ocupado não faça seu build falhar, sem martelar o serviço limitado.
Applying this to your pipeline
- Measure before changing. Most CI optimisation targets the wrong step because the slow one is assumed rather than timed.
- Cache what is expensive to produce and cheap to validate, and key the cache to the exact tool version.
- Fail fast: run the cheapest checks that can reject a change first, so an expensive job never starts on code that cannot pass.
- Prefer determinism over speed when they conflict. A fast pipeline nobody trusts gets re-run, which is slower than a slow one that is believed.
Principais conclusões
- Um erro de rate limit rejeita requisições por exceder uma taxa permitida (muitas vezes 429).
- A CI atinge limites via pulls paralelos, requisições não autenticadas e rajadas.
- Respeite o Retry-After; espere em vez de fazer retry imediato.
- Ele é transitório e passível de retry, mas apenas com backoff.