Repository navigation
OMO Harness Stream Consumer Deadlock: LLM stream hangs indefinitely #31122
Description
Bug Description
The OMO harness stream consumer can deadlock indefinitely when an LLM provider stops emitting events but never closes the stream. This was observed with Kimi K2.6 in thinking mode, where the stream hung for 36 minutes until manually cancelled.
Reproduction Steps
- Configure an agent to use Kimi K2.6 with variant "high" (thinking enabled)
- Trigger a plan creation via
task(subagent_type="plan", ...) - The stream starts but after some events, no more events are emitted
- The stream consumer waits indefinitely with no timeout or error
- After 36 minutes, the user must manually cancel the session
Expected Behavior
The stream should timeout if no events are received for a reasonable period (e.g., 5 minutes) and emit an error event to allow graceful degradation.
Actual Behavior
The stream consumer hangs forever, waiting for the next event that never arrives.
Environment
- OpenCode version: 1.16.2
- Provider: Kimi For Coding (kimi-k2.6)
- Variant: high (thinking enabled)
- OS: macOS
Root Cause
In packages/opencode/src/session/llm.ts, the AI SDK fullStream is converted to an Effect Stream without any timeout between events. When the provider stops emitting but doesn't close the stream, Stream.fromAsyncIterable waits forever.
Proposed Fix
Add Stream.timeout and Stream.catchCause to handle the timeout gracefully, ensuring the stream errors out after 5 minutes of inactivity instead of hanging indefinitely.
Activity
github-actions commentedon Jun 6, 2026
This issue might be a duplicate of existing issues. Please check:
llm.tsstream idle timeout gap and proposes the same fix direction.chunkTimeoutfails for non-SSE streaming protocols (AWS Bedrock/EventStream), which is another manifestation of the same missing stream-level timeout protection.Please review those issues and consider whether this is already tracked there before proceeding.
Davide95 commentedon Jul 28, 2026
This is still happening on OpenCode 1.18.8 on macOS.
I observed streams remain open indefinitely after network/VPN interruptions. In some cases no response arrived; in another, one text chunk arrived and the stream then remained silent for 57 minutes. The OpenCode process stayed healthy, but there was no stream error, retry, or exiting loop log. Manual cancellation was required.
Clean TCP failures are retried correctly. The problem occurs when the connection becomes half-open and no error reaches OpenCode.
This has occurred across multiple providers, so it does not appear provider-specific. Foreground tasks also remain blocked indefinitely when the affected stream belongs to a subagent.
Davide95 commentedon Aug 5, 2026
Ciao @StarpTech! I have a PR that likely fix it, and I've already tested it with ~10 candidates, who reported it solves their issue. LMK if I can help in any way :)
opencode-agent commentedon Oct 1, 2026
The provider timeout options now default to five minutes (300,000 ms):
provider.<provider-id>.options.headerTimeoutlimits the wait for response headers, andprovider.<provider-id>.options.chunkTimeoutlimits inactivity between streamed SSE chunks. You can set either option to another duration in milliseconds, or tofalseto disable it.Closing this issue as addressed for stalled SSE streams. Thanks for the report!