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

Reduce repeated Codex uploads and lossless continuation spill traffic

Aperta
  • Qualcosa non va?
#7,905 2 commenti 1 reazione 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
12/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
bun, typescript
Ambito
backend, networking

Direzione di ricerca

The payload names no source files or tests. Start with the upstream WebSocket continuation path that omits an acknowledged input prefix, and find where idle sockets are retired at three minutes and twenty minutes of age. Then find the continuation storage that keeps cumulative records per response ID. Related work is #7806. Done means longer bounded socket retention with lossless compressed spill envelopes, legacy reads still working, and the isolation and cancellation behaviour kept intact.

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

Descrizione

enhancement streaming
Area

Streaming; proxy and routing; continuation storage

What are you trying to accomplish?

Keep long-running native Codex sessions from repeatedly uploading the same history, and reduce continuation-cache disk writes without losing replayable context. Ship the behavior upstream so normal package upgrades do not remove locally maintained optimizations.

What prevents this today?

An opt-in upstream WS continuation can already omit an acknowledged, exactly matching input prefix, but the current local extension retires idle sockets after three minutes and by twenty minutes of total age. A later request then uploads the whole history again even when its model, admitted caller, account, thread and route are unchanged.

Local continuation storage also retains cumulative input/output records per response ID. Large repeated records create substantial spill traffic. Merely increasing the cache budget postpones eviction and retains more duplicated data.

What should OpenCodex do?
  • Keep completed, eligible connections warm for a bounded longer interval when incremental upload is enabled, without raising socket-count, exchange-count or retained-prefix memory limits.
  • Continue only from a completed response belonging to the same admitted caller and unchanged history/envelope. Preserve account/credential/route isolation, cancellation and UNKNOWN/failure behavior.
  • Store profitable continuation spill records losslessly in bounded, self-contained compressed envelopes. Preserve legacy reads, original item content, response IDs, thread isolation and decoded-size limits; do not create fragile parent-file dependencies.
  • Include this behavior in the supported release path. A local workaround should refuse an incompatible update before replacement rather than silently start an unpatched package.
Example usage or interface

With codexWsIncrementalUpload: true, an isolated test using real Bun WebSockets sends two otherwise equivalent requests with a simulated four-minute idle gap:

Measurement Original retention Longer bounded retention
First create bytes 278,631 278,631
Second create bytes 278,751 148
Physical connections 2 1
Logical creates 2 2

For storage, a bounded read-only sample of eight existing continuation records encoded from 20,913,583 to 14,245,022 bytes (31.9% fewer physical bytes), with exact decoded-content equality. This is a sample, not a promised production reduction. WS JSON savings are not billing savings, whole-interface traffic, or a comparison against compressed HTTP.

Alternatives or workarounds

Local source patches demonstrate the benefit but can be replaced by package upgrades. Blanket history truncation changes the model's context; retaining more raw snapshots increases resource use. Self-contained compression avoids introducing cross-file recovery dependencies. Older readers cannot decode the new envelopes, so rollback must retain the decoder until those records expire.

Additional context

Related implementation: #7806. The follow-up preserves its admitted-caller scoping and live-config binding fixes. Local validation uses synthetic loopback providers and isolated storage; no production prompts, credentials or account identifiers are included.

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
16h 25m
PR unite (30g)
706

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.