Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Chiusa Adatta ai principianti
#7,802 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
75/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
api, backend

Direzione di ricerca

Leggi il percorso di retry di Google in src/adapters/google-http.ts e il comportamento di retryBackoffDelayMs in src/lib/upstream-retry.ts; confronta l’uso attuale dell’opzione in src/web-search/executor.ts e src/server/responses/agent-task-recovery.ts. Imposta retryAfterIsLowerBound: true per i retry di Google, mantenendo i retry limitati e la cancellazione. Il lavoro è completato quando un Retry-After di 30 secondi non attiva mai un retry anticipato e una scadenza che non consente di attendere restituisce la risposta originale.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement provider tools
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.
Lingua principale
TypeScript
Stelle
16.9k
Fork
1.3k
Merge medio
15h 24m
PR unite (30g)
678

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di lidge-jun/opencodex

Tutte le issue di lidge-jun/opencodex

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.