Re: [PATCH v2 2/4] http: add exponential backoff without Retry-After

From: Ravi Mistry <rmistry@google.com>
Date: Nov 5, 2026, 00:10 UTC
Message-ID: <CAF+mdifcp+qkESZzd=8SmrL6eckxAQXR-4nxxSuL=xCV48OhVQ@mail.gmail.com>
In-Reply-To: <auusPUaYRmUBDsdI@fruit.crustytoothpaste.net>

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

Show 6 quoted lines

> 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.

If 1s sounds reasonable, I can send a v3 with that change.

Thanks!