[Feature]: Respect Google Retry-After as a lower bound for retries #7802

Area

Provider adapters

What are you trying to accomplish?

Respect a Google upstream Retry-After delay and do not retry earlier than requested.

What prevents this today?

In published 2.92.0 the Google retry path calls retryBackoffDelayMs with maxDelayMs: GOOGLE_RETRY_MAX_MS (2,000 ms, src/adapters/google-http.ts:24) and without retryAfterIsLowerBound (src/adapters/google-http.ts:140). Without that option the helper returns min(retryAfter, maxDelayMs) (src/lib/upstream-retry.ts:418), so a longer server delay is cut to 2 s. A direct helper call with Retry-After: 30, base 250 ms and maximum 2,000 ms returned 2,000 ms; with retryAfterIsLowerBound: true it returned 30,000 ms.

What should OpenCodex do?

Pass retryAfterIsLowerBound: true in the Google retry path, as src/web-search/executor.ts:149 and src/server/responses/agent-task-recovery.ts:557 already do. If the request deadline cannot wait that long, return the upstream response instead of sending early. Keep bounded retries and cancellation.

Example usage or interface

For a synthetic retryable Google response with Retry-After: 30, no next send happens before 30 seconds. With a shorter deadline, the original response is returned without a retry.

Alternatives or workarounds

Disable or limit retries when the upstream asks for a longer delay.

Additional context

We read the source and called the helper directly. We did not send a request through the full Google adapter or to a live Google endpoint.

Related: #5778 (combo single-target retry after cooldown, merged), #5716 (bounded server Retry-After target cooldowns, closed), #7426 (rotate to another account on 429, open). Those change combo and account cooldowns; this request is about the in-adapter retry delay.

Checks

• I searched existing issues and documentation.
• This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
• I removed secrets and personal data.