Repair Retry-After Header & Backoff Handling Bugs

FAULT BOUNDARY IDENTIFIED

Case analyzed

An API client respects Retry-After after 429 responses. Numeric values work, but an HTTP-date value is parsed in local time and can become negative on machines outside UTC. Negative delays are treated as zero, causing an immediate retry burst. The client also ignores its 30-second overall retry budget when the header requests 120 seconds.

The supplied facts are sufficient to perform a concrete repair diagnosis for this case. No repository, production, vendor, or legal access is assumed.

Verified evidence

• VERIFIED: Numeric Retry-After works.
• VERIFIED: HTTP-date is incorrectly parsed using local time.
• VERIFIED: Negative computed delays trigger immediate retries.
• VERIFIED: A 30-second overall retry budget exists but a 120-second header can override it.

Concrete findings

1. HTTP-date must be parsed as an absolute UTC instant; local-time parsing explains the negative delay outside UTC.
2. A negative computed delay must not become an immediate synchronized retry; route it through bounded retry policy.
3. Retry-After is server guidance, not authority to exceed the client's 30-second total retry budget.
4. For 503 Retry-After: 15, preserve the minimum wait but add bounded positive jitter so hundreds of workers do not wake together.
5. The sleep must observe cancellation.

The canonical acceptance rule is

Retry-After handling is safe only when both legal formats are parsed consistently, negative or extreme values are bounded, retry budgets and cancellation remain authoritative, and server guidance does not create synchronized retry storms.

The current result is based on that invariant, not on a generic success banner or a reusable checklist.

Required actions

1. Delta-Seconds Parsing: repair the ownin