On 2026-11-03 at 18:57:25, Ravi Mistry via GitGitGadget wrote:
From: Ravi Mistry <redacted>
When a server returns HTTP 429 without a Retry-After header, Git waits
the same fixed http.retryAfter delay on every retry. If that delay is
short (e.g., 1s), Git burns through all of its retries in just a few
seconds before a busy server can recover. If that delay is long, even a
brief glitch has to wait a long time on the first retry.
Pass the 1-based retry attempt count to handle_rate_limit_retry() and
double http.retryAfter on each subsequent retry (1s, 2s, 4s, ..., via
http.retryAfter * 2^(attempt - 1)), clamping the delay at
http.maxRetryTime. This keeps the first retry fast while giving the
server more time to recover on later attempts, matching curl's own
--retry behavior (while keeping http.retryAfter's existing default of 0
for immediate retries when unconfigured). When the server provides an
explicit Retry-After header, continue to honor the server-provided delay
(or fail fast if it exceeds http.maxRetryTime).
We should not immediately retry on a 429 response, even if that's the
behaviour we have now. The server told us we were being too aggressive,
so the exact thing we should not do is to continue making requests. As
a server operator, I definitely don't want this behaviour; instead, we
should pick something sensible if no Retry-After is given, such as 30
seconds.
--
brian m. carlson (they/them)
Toronto, Ontario, CA
Speaking for myself only