Handle provider 429s without a retry storm

What Relay does

When an upstream returns 429 or a compatible throttle signal, Relay reads Retry-After when available, records the endpoint as cooling down, and requeues the affected task. If no usable delay is supplied, bounded backoff is applied.

This keeps retry timing in one scheduler instead of letting every caller start an independent retry loop.

Configure the path

1. Add realistic configured limits for the endpoint/provider.
2. Leave observed-limit learning enabled when the upstream exposes usable rate headers.
3. Set a lane wait budget appropriate for the workload.
4. Add explicitly ranked alternative endpoints when you need fallback for other failure classes.
5. Watch queue and endpoint health views during a controlled test.

Important distinction

Do not document current 429 handling as “instant provider failover.” The affected in-flight task is requeued against its selected endpoint. While that endpoint is cooling, later candidate selection can avoid it. Connection failures, timeouts, and 5xx responses use the explicit failure-fallback path when fallback is enabled.