https.ts exponential backoff strategy.

[kiritocode1]

in @https.ts, why do we use exponential backoff strategy?

If you get a 429 error, it should return a RetryAfter header with a value of the number of seconds to wait before retrying.
I think the exponential backoff strategy is avoided by the client once you get a 429 and that sould be accounted for.

[Codimow]

fixed this and synced it across both repos.

what I changed:

• Stopped generic exponential retry for 429.
• Now 429 only retries when Retry-After is present and valid.
• Supports both Retry-After formats (seconds + HTTP date).
• Updated tests so 429 without Retry-After does not retry.

ty for pointing it out blank

[SirBrenton]

This looks like the right change — treating Retry-After as the contract instead of layering exponential backoff on top.

One small invariant worth preserving if jitter gets introduced later:
Retry-After should act as a floor, not a target.

i.e. delay = max(retry_after, jittered_delay) so the client never retries earlier than the server requested.

[Codimow]

yep, fully agree: if jitter is added later, Retry-After stays a floor, not a target.

we should always wait at least Retry-After (never earlier) and only wait longer if jitter/backoff computes longer.