SSE stream silently dropped mid-response hangs session/subagents forever — chunkTimeout has no default on the openai path #37580

Activity

1. github-actions

   assigned

   nexxeln

   on Jul 18, 2026
2. github-actions commented on Jul 18, 2026

   

   github-actionsBot

   on Jul 18, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • Tasks/Subagents with Codex / OpenAI are frequently getting stuck with no timeout/retry, which then hangs the session forever #11865: Tasks/Subagents with Codex/OpenAI frequently getting stuck with no timeout/retry, hanging the session forever (same provider path, same symptom)
   • OpenAI stream intermittently freezes in working state with high CPU and idle HTTPS socket #29129: OpenAI stream intermittently freezes with idle HTTPS socket — log stops at stream start, process stays alive indefinitely (nearly identical diagnosis and root cause)
   • [BUG] Subagents hang indefinitely after quick bash tool call - stream never times out (Aborted, stack=undefined) #33028: Subagents hang indefinitely after bash tool call — stream never times out (same missing-timeout root cause)

   Your issue adds valuable specifics (the chunkTimeout code path analysis, wrapSSE only armed when the option is explicitly set, and the ss -K workaround), which may help move those issues forward.
3. VINODvoid commented on Jul 21, 2026

   

   VINODvoid

   on Jul 21, 2026

   More actions

   Dug into this on dev — the diagnosis holds up. In packages/opencode/src/provider/provider.ts, wrapSSE only kicks in if a positive chunkTimeout is passed (L38), otherwise it hands the SSE body straight back unwrapped. The openai provider sets a headerTimeout (L208) but never a chunkTimeout, and the header one only covers time-to-headers. So once headers land, a dead stream just sits on reader.read() forever, nothing throws, and none of the retry layers ever get a chance to fire. Lines up with what you saw.

   Good news is the recovery already works when chunkTimeout is set — wrapSSE throws ResponseStreamError, it gets mapped to a retryable error, and the turn retries on its own. So it's genuinely just a missing default.

   Fix is basically adding one next to the header default:

   const OPENAI_CHUNK_TIMEOUT_DEFAULT = <value>   // near L35
   options: { headerTimeout: OPENAI_HEADER_TIMEOUT_DEFAULT, chunkTimeout: OPENAI_CHUNK_TIMEOUT_DEFAULT }  // L208

   Two things I'd rather not guess at, since this hits every OpenAI user. First, the value — it triggers on silence between chunks, and reasoning models can go quiet for a while mid-thought, so too low and you'd kill real streams. Your 120s seems safe; I'd maybe go 180s to be safe. Second, scope — meta, xai, github-copilot and azure all stream through the same path with no timeout either, so should this default cover just openai or all of them?

   Once that's decided I'm happy to open a PR with a test for it.
4. niStee commented on Aug 24, 2026

   

   niStee

   on Aug 24, 2026

   More actions

   Additional data point: same silent-stall signature on the litellm provider path (model minimax-m3), opencode 1.18.18, Linux — so this is not specific to the openai/ChatGPT transport.

   Evidence comes from a read-only investigation of the local session DB (~/.local/share/opencode/opencode.db, queried via SQLite; evidence-snapshot SHA-256 e31c2347304401f99fdc2332b3f903c42b708d7b7a629ed3847e80b27bed9c08) plus scoped runtime-log records. The active process was never interrupted.

   Affected main session ses_fd8d98c6cffePtOPVMJZv51ocX (agent build):

   • Repeated stream providerID=litellm modelID=minimax-m3 log records with long gaps between them — dispatch happens, then silence, matching the "log stops and never logs another line" pattern described above.
   • 15 assistant messages with null finish; the latest unfinished message's tool part (prt_033dfb886001C0mXLSKDy4cp5q) remained persisted as running at inspection time.
   • Max wall-clock gap between consecutive persisted parts: 43,084.30 s (~12 h).

   Cohort context (all local minimax-m3 sessions; pre-registered descriptive thresholds, 60 s cutoff):

   • 190 sessions total (16 main, 174 child); 83 timestamp-qualified.
   • 10 controls (median max-gap 21.23 s), 34 strict incidents (median max-gap 132.85 s), 39 unclassified (null-finish and no-stop subtypes kept separate, not imputed).
   • Sensitivity over all 83: >=30 s: 59, >=60 s: 48, >=120 s: 25, >=300 s: 18, >=600 s: 14, >=1800 s: 9.

   This supports the provider-neutral idle watchdog in #40010 covering non-openai providers by default. I will set provider.litellm.options.chunkTimeout as a workaround and can report back whether the incident rate drops.

   (Local paths and machine details sanitized; stable IDs retained so I can run follow-up queries if maintainers need them.)
5. moaines commented on Sep 7, 2026

   

   moaines

   on Sep 7, 2026

   More actions

   Independent corpus confirming this for pre-default binaries, plus one hang surviving the default — opencode v1.18.29, Linux, openai-compatible gateway (z-ai/glm-5.3-flash), code dev@57ef382843.

   Corrected mining (aborts excluded): 341 assistant messages with empty finish → ~308 ordinary aborts (MessageAbortedError + time.completed set) to exclude + 11 fast aborts with completed present to distinguish → 22-33 true hangs by strictness (finish NULL + error NULL, never completed). In-flight message excluded — same DB signature as a hang.

   31/33 sampled hangs (94%) are on binaries 1.1.49→1.18.27 without default (before 04 Sept 19:26) — matches the reported bug. But one authentic hang 2026-09-07 11:57 occurred under 1.18.29 with the ?? 300_000 default active (provider.ts:1795-1796, literal present in installed binary): ses_f845f8ac, delta 2ms, time.completed NULL. The default does not eliminate all hangs.

   Two shapes, part rows confirm chunk-by-chunk persistence:

   • zero-byte: 0 parts, lifetime <1s. ex msg_0795edebc0011V1CkxmazEnIwu, 28ms.
   • stall after start: ex msg_07943d23d001CJcskVN90yYPpn, 108s of reasoning persisted, then silence.

   Provider was reachable: parallel stream on same API/model succeeded at the same second (logs 00:57Z). Zero timeout / retry / ECONNRESET lines in hang windows; only the later manual cancel + Aborted.

   Code lead (dev@57ef382843, not ground truth): wrapSSE arms only if content-type contains "text/event-stream" (provider.ts:37-40) — a gateway answering otherwise (SSE-in-JSON, chunked) escapes the guard.

   Workaround validated in prod:
   { "provider": { "<id>": { "options": { "chunkTimeout": 120000 } } } }

   Does wrapSSE's content-type check leave non-SSE streaming responses unguarded, and should the guard cover those?

   Searched SSE hang, chunkTimeout — related: #46692, #43519.

   Full DB row dumps (metadata only: version, model, provider, deltas, part counts) available on request.
6. rekram1-node commented on Oct 2, 2026

   

   rekram1-node

   on Oct 2, 2026

   Contributor

   More actions

   Fixed in #46890 (v1.18.27) and #49229 (v2.0.22).

   🎉React with 🎉1Reacted by Nils
7. rekram1-node

   closed this as completedon Oct 2, 2026