git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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
Previous: Ravi Mistry via GitGitGadgetNext: Ravi Mistry
Message 16 of 20 in “http: exponential backoff, configurable status codes, and post_rpc() retries”
  1. 0/4 http: exponential backoff, configurable status codes, and post_rpc() retriesRavi Mistry via GitGitGadget, Oct 31, 2026
  2. 1/4 http: fix retry count and Retry-After timingRavi Mistry via GitGitGadget, Oct 31, 2026
  3. Junio C HamanoNov 3, 2026
  4. Ravi MistryNov 3, 2026
  5. 2/4 http: add exponential backoff without Retry-AfterRavi Mistry via GitGitGadget, Oct 31, 2026
  6. Junio C HamanoNov 3, 2026
  7. Ravi MistryNov 3, 2026
  8. 3/4 http: add http.retryStatusCodes config optionRavi Mistry via GitGitGadget, Oct 31, 2026
  9. Junio C HamanoNov 3, 2026
  10. Ravi MistryNov 3, 2026
  11. 4/4 remote-curl: retry transient HTTP errors in post_rpc()Ravi Mistry via GitGitGadget, Oct 31, 2026
  12. Junio C HamanoNov 3, 2026
  13. 0/4 http: exponential backoff, configurable status codes, and post_rpc() retriesRavi Mistry via GitGitGadget, Nov 3, 2026
  14. 1/4 http: fix retry count and Retry-After timingRavi Mistry via GitGitGadget, Nov 3, 2026
  15. 2/4 http: add exponential backoff without Retry-AfterRavi Mistry via GitGitGadget, Nov 3, 2026
  16. brian m. carlsonNov 4, 2026
  17. Ravi MistryNov 5, 2026
  18. 3/4 http: add http.retryStatusCodes config optionRavi Mistry via GitGitGadget, Nov 3, 2026
  19. Junio C HamanoNov 3, 2026
  20. 4/4 remote-curl: retry transient HTTP errors in post_rpc()Ravi Mistry via GitGitGadget, Nov 3, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.