Provider stream dies silently mid-run after a tool batch (GLM-5.3 via nvidia, 1.18.34) — session hangs forever, no error #53083

Description

Provider stream silently dies mid-run (after a tool batch), leaving the session running forever with no error. Two clean repros, same evening, same signature.

Environment

• opencode 1.18.34 (latest release, opencode serve on port 4096, WSL2 Ubuntu 22 on Windows 11)
• Provider: nvidia (NVIDIA NIM), model z-ai/glm-5.3
• Client: custom harness consuming the HTTP API + SSE /event stream (session created via POST /session, prompt via POST /session/{id}/prompt_async, events via GET /event)

Signature (identical in both repros):

1. Session works normally for several steps — each assistant step with tool calls (bash/read/glob) completes in seconds, tool results stream back, message.part.updated events flow.
2. Then a step issues a small tool batch (2 calls: read + bash). One tool result returns (bash completes — ✓ event arrives). The other (read) stays pending.
3. From that moment: zero events, zero parts, no error, no retry. The session stays "running" indefinitely. No stream error in the log, nothing.
4. Server-side POST /session/{id}/abort recovers it; the next prompt in the same session (or a new session) goes through fine — every retry so far has succeeded.

Repro 1 (2026-10-03 20:49 → 21:19 local): 4 steps in 18 s, then the described tool batch at +2 min, then 28 minutes of silence until our 30-min watchdog aborted it. Aborted read part shows "Tool execution aborted" only after the abort.

Repro 2 (21:49 → 21:57): 3 steps in ~2 min, same batch shape, 6.5 min of silence when we cancelled manually.

Relevant observations

• A concurrent interactive CLI session on the same opencode server, same provider+model, running far heavier tool traffic for hours (including many parallel read+bash batches), never hung — which points at the server's per-session stream/prompt path rather than the provider or the API key.
• Plain-HTTP streaming to the same model family is reported unaffected in Client busy-loops (~85% CPU, zero syscalls) on long Fireworks reasoning streams — probabilistic, reproducible on 1.17.6 and 1.18.31 #49880's methodology; our provider (NVIDIA NIM, GLM-5.3) matches the GLM-5.3-family reasoning-stream hang profile described there.
• This looks like the same family as Client busy-loops (~85% CPU, zero syscalls) on long Fireworks reasoning streams — probabilistic, reproducible on 1.17.6 and 1.18.31 #49880 (probabilistic GLM reasoning-stream hang), opencode proxy gateway SSE stream hangs silently with zero chunks #43007 (zero-chunk silent stream), UI hangs indefinitely when LLM stream fails mid-flight (fetch failed / network drop) #46583 (UI hangs when stream fails mid-flight), fix(opencode): prevent shell tool hang on fast process exit #50542 (tool call stuck at running forever).

Ask

• Enforce an inter-chunk / first-chunk timeout on the provider stream and terminate the session turn with a hard error instead of hanging silently.
• Or expose a way to detect a dead stream from the event stream, so clients can self-heal without a fixed timeout guess.

Happy to provide DB part timelines (we have precise per-part timestamps for both repros) if useful.

Plugins

None.

OpenCode version

1.18.34

Steps to reproduce

1. opencode serve (1.18.34) with a GLM-5.3 model (provider nvidia).
2. Drive it via the HTTP API: create session, prompt_async, consume GET /event.
3. Issue a broad discovery-style prompt (ours: "where were we in the project?" / "list all objects in the project") that triggers multi-step tool use including parallel read+bash.
4. Observe: activity flows, then a tool batch where one result returns and the other never does; no further events arrive; session stays busy indefinitely.

Screenshot and/or share link

N/A (headless client; can provide part timelines from opencode.db on request)

Operating System

Linux (WSL2 Ubuntu 22.04 on Windows 11)

Terminal

N/A (HTTP API client)