Provider stream hangs silently: no timeout, no error, no UI feedback; assistant message persisted empty (0 tokens) #59872

Activity

1. opencodejr commented on Oct 28, 2026

   

   opencodejrBot

   on Oct 28, 2026

   More actions

   Thanks for the detailed report and the logs!

   You're on opencode 1.18.21, which is OpenCode v1. v1 now only gets fixes for critical bugs (data loss, security problems, or breakage with no workaround). Since Esc + resend works around this hang, it's unlikely to be fixed in v1.

   We'd encourage you to try v2 (@opencode/cli, the opencode command), where active development happens. I can't promise v2 already handles this differently. Similar stream-hang problems are being tracked there. In order of how closely they match:

   • server: model step hangs with no timeout, session stays busy until interrupted #53747: v2 model step hangs with no timeout; the session stays busy until interrupted
   • fix(ai): bound native stream stalls on framed events #52866: open PR to bound native stream stalls
   • cli: provider stream failures retry silently forever - looks like a hang with no console feedback #49030: provider stream failures retry silently, which looks like a hang
   • Turn dies silently mid-stream: session stays busy forever, queued prompts never run, no abort/status endpoint #59559: a turn dies silently mid-stream and the session stays busy
   • session: empty assistant response (content=[], finish=stop) ends turn silently as succeeded #59518: an empty assistant response ends the turn silently as succeeded (close to the empty, 0-token message you saw)

   If you see the same hang on v2, or think this is critical in v1, please reply here with the v2 version and logs.
2. opencodejr

   added

   pending close

   triaging

   on Oct 28, 2026
3. gonzaloguzmans commented on Oct 28, 2026

   

   gonzaloguzmans

   on Oct 28, 2026

   Author

   More actions

   Update — likely root cause found, and it is not (only) the provider

   Retested after the user's retries kept hanging. New evidence:

   1. The hang is project-correlated, not provider-wide. The very same provider/model (opencode-go / glm-5.3-flash) streams instantly in a session whose cwd is a different project, while every hung request belongs to a session with cwd=/Users/gonzalo/Documents/cubo345 — including a brand-new session whose first short message hung at 09:58:56Z.

   2. That project's git object store is corrupt. /Users/gonzalo/Documents/cubo345/.git/objects/pack/pack-78c247bfae5271ac5bdb04542acb83b57e1f240c.pack is truncated (145,231,109 bytes against an idx from Oct 16 that does not match it; pack mtimes rewritten Oct 19 10:07). The opencode log has spammed git errors since 2026-10-19T14:18Z:

      error: file .../pack-78c247....pack is far too short to be a packfile (repeated hundreds of times)
      fatal: unable to read 004145cddf3f9db91b57b9cb596683c8eb420862
      fatal: could not finish pack-objects to repack promisor objects
      fatal: failed to run repack
      

      The repo is a partial clone (blob:none promisor packs), so git operations that hit missing/corrupt objects trigger fetches against the promisor remote. If such a git invocation blocks (hung fetch / lock), opencode's pre-stream preparation never finishes and the LLM request is never opened — which exactly matches the observed signature: loop step=0 logged, no stream line, no ERROR, no retry, empty assistant message persisted with 0 tokens.

   3. Retries (interrupt + resend at 10:34:47Z and 10:35:55Z) hung with the identical signature, reproducing 100%.

   So the earlier framing ("provider accepts the request but never sends bytes") should be amended: the LLM request likely never gets sent in these cases — the hang occurs in opencode's git-dependent preparation for that project. Two hardening suggestions stand:

   • Put a deadline/timeout around the whole message-preparation phase (including any git calls, especially promisor fetches) and surface an error to the UI instead of hanging silently.
   • Don't persist the assistant message until the stream actually produces output.

   (Notably, one earlier turn in the same corrupt-repo session did stream successfully at 09:44:39Z, so the blocking git path is hit intermittently — plausibly depending on which git operation/message-prep path runs.)
4. gonzaloguzmans commented on Oct 28, 2026

   

   gonzaloguzmans

   on Oct 28, 2026

   Author

   More actions

   Timing confirmation: the 10:35:55Z attempt released at 10:40:22Z and streamed to completion normally (~14 s, 390 output tokens). The release coincides to the minute with a write finishing on the repo object store: listing /Users/gonzalo/Documents/cubo345/.git/objects/pack/ at 10:32Z showed pack-b8aec5a0....pack with mtime "Oct 19 10:07"; listing it again at 10:48Z showed mtime "Oct 28 07:40" local (= 10:40Z). Nothing external touched the repo between the listings; the blocked git operation itself completed after ~4.5 min and unblocked opencode message prep, which then opened the LLM stream instantly. No git processes or .lock files remain. The corrupt pack-78c247....pack is untouched, so the intermittent hang remains reproducible.
5. opencodejr

   closed this as not plannedon Oct 29, 2026
6. opencodejr commented on Oct 29, 2026

   

   opencodejrBot

   on Oct 29, 2026

   More actions

   Closing this as not planned. You reported it on opencode 1.18.21 (v1), and v1 now only gets fixes for critical bugs. This hang has a workaround that works (Esc + resend), and we haven't heard that it also happens on v2.

   If you see the same silent hang or the empty 0-token assistant message on v2 (@opencode/cli), please open a new issue with the v2 version and logs, or comment on #53747 if it matches. Thanks again for the detailed report!
7. opencodejr

   reopened this on Nov 3, 2026