[bug] combo Retry-After can quarantine a target effectively indefinitely #5686

Client or integration

Direct HTTP/API client

Area

Proxy and routing

Summary

On official v2.63.0, explicit provider Retry-After values can become authoritative combo cooldowns without a practical upper safety bound. A malformed numeric or HTTP-date value can effectively quarantine a target for an extremely long period. Expected: preserve legitimate server delays, including multi-hour windows, but apply a finite safety ceiling. A 24-hour cap preserves normal semantics while preventing pathological quarantine.

Reproduction

1. Configure a failover combo with at least two targets.
2. Make one target return a retryable failure with an extremely large numeric or HTTP-date Retry-After.
3. Observe the target cooldown derived from that server delay.
4. Compare with ordinary local fallback cooldowns, which are bounded separately.
5. A local patch caps only explicit server-delay preservation at 24 hours; short and multi-hour values remain authoritative.

Version

2.63.0 / commit 96b1406

Operating system

Ubuntu Server Linux x86_64

Provider and model

Not provider-specific

Logs or error output

No crash is required. The defect is the unbounded cooldown duration derived from a pathological Retry-After value.

Screenshots and supporting files

Locally validated with numeric and HTTP-date Retry-After regression coverage. The combined post-2.63 candidate passes the full native suite and static gates.

Redacted configuration

{"combo":{"strategy":"failover","targets":["provider-a/model-a","provider-b/model-b"]}}

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.