On 2026-11-05 at 00:10:10, Ravi Mistry wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> > 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.
> 
> Makes sense. Junio noted on v1 as well that defaulting http.retryAfter
> to 0 does not mesh well with exponential backoff.
> 
> What do you think about defaulting http.retryAfter to 1 second, matching
> curl's --retry behavior (1s, 2s, 4s, ...)? Because the delay doubles on
> each attempt (and Patch 3/4 also reuses http.retryAfter for opt-in
> transient 5xx retries), starting at 30s would turn 3 retries into 30s,
> 60s, and 120s. Starting at 1s avoids hammering the server immediately
> while ramping up on repeated failures.

I can't imagine a situation where 1s is a reasonable backoff for a 429
response since I can't imagine how the load could reasonably decrease in
that amount of time.  I suggested 30 seconds because that's a reasonable
amount of time to back off and allow load to go down (and I think that
30, 60, and 120 seconds is a reasonable set of timeframes), but I'd say
it should be at the very least 10 seconds.  I've seen cases where users
retry very aggressively and it increases the load on the server so they
just get rate-limited way, way more than if they'd been more gentle and
waited a little bit longer.

Note that the curl binary often makes very cheap requests, such as
static pages or small files, but we are making what are almost certainly
very expensive requests requiring a substantial amount of server
computation, so the curl defaults are almost certainly not right here.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA
Speaking for myself only