Self-Healing CI: Auto-Retrying a PyPI 429 Rate Limit
A pip install that dies on "HTTP error 429 while getting" was rate limited by PyPI, not served a broken package: the same requirement installs cleanly once the window resets.
The problem
pip fails partway through installing requirements with an HTTP 429 from files.pythonhosted.org. The package exists and the version is valid. CI runners share egress addresses with a large number of other jobs, so a busy window on a shared IP can exhaust the anonymous request budget even though your own job is small.
ERROR: HTTP error 429 while getting https://files.pythonhosted.org/packages/aa/bb/requests-2.31.0-py3-none-any.whlWhy it happens
pip reports 429 only on the wheel-download path, at the point it abandons the attempt. The index request usually succeeds, so the failure lands mid-install with some packages already resolved, which is why it reads like a corrupt environment rather than a throttle.
Hosted CI egresses through shared address pools. The budget is consumed by every job on that address, so a run can be throttled without doing anything unusual itself.
The manual fix
Manual mitigations for a PyPI rate limit:
- Re-run the job after a few minutes, once the window has reset.
- Point pip at an internal index or pull-through mirror so CI stops competing for the shared anonymous budget.
- Cache the wheel directory between runs so a repeat install does not re-download anything.
pip install --retries 5 --timeout 30 -r requirements.txtHow this gets automated
A 429 is unambiguous: it is a throttle with a reset window, not a packaging error, so the only correct response is to wait and try again. The wait has to be long, because the window is measured in minutes rather than seconds. A self-healing pipeline recognizes the 429 frame, backs off well past the usual retry interval, and re-runs the install rather than failing the job on a limit that has already expired by the time anyone looks at it.