Re: [PATCH v2 2/4] http: add exponential backoff without Retry-After
- From
brian m. carlson <sandals@crustytoothpaste.net>
- Date
- Nov 4, 2026, 22:05 UTC
- Message-ID
- <auusPUaYRmUBDsdI@fruit.crustytoothpaste.net>
- In-Reply-To
- <fe1e847dede7579da911b5a9ba16c806b5332723.1793732247.git.gitgitgadget@gmail.com>
On 2026-11-03 at 18:57:25, Ravi Mistry via GitGitGadget wrote:
Show 17 quoted lines
> From: Ravi Mistry <rmistry@google.com> > > 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