You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
GPT-5.6 Sol intermittently fills OpenCode's inbound Responses WebSocket queue. The TUI shows:
Retry due · attempt 2 · WebSocket inbound queue overflow
The current turn recovered on retry. The same machine previously recorded the identical error as a terminal Failed to drain Session, so this can also fail the whole turn.
The current v2 branch has the same file byte-for-byte. Existing tests correctly require poisoning rather than silently dropping frames, but an ordinary provider stream should not reach this internal guard. Temporary consumer lag should use safe backpressure, larger/batched buffering, or recovery that does not terminate the turn.
A repository search found no matching bug report. #42572 concerns oversized outbound requests/code 1009; #48690 concerns xAI close code 1006. Neither covers inbound queue exhaustion.
Relevant prior server log, with paths and session ID redacted:
Reproduced on v2 at 37ff501cc6a3 with a local WebSocket server: pause the consumer, send 1,024 small frames, then resume. The current transport fails at frame:128 instead of delivering the burst in order. No provider credentials are needed.
There is also a second fail-on-full 128-frame queue in SessionModelTransport, so changing only the socket adapter would leave the session path vulnerable to consumer lag. I’m checking bounded ingress buffering at the socket boundary and awaited queue offers at the async session boundary, including cancellation and connection reuse.
@neriousy, please flag if you already have a fix underway; I’m preparing a focused patch and regression evidence for this issue. This work is AI-assisted.
Fixed by #50026 and released in v2.0.11. The two fail-on-full 128-frame WebSocket ingress queues were replaced with unbounded handoff queues, with a regression test covering a synchronous 1,500-frame burst. Closing as fixed.
Activity
maximilliangrand commentedon Sep 17, 2026
Reproduced on
v2at37ff501cc6a3with a local WebSocket server: pause the consumer, send 1,024 small frames, then resume. The current transport fails atframe:128instead of delivering the burst in order. No provider credentials are needed.There is also a second fail-on-full 128-frame queue in
SessionModelTransport, so changing only the socket adapter would leave the session path vulnerable to consumer lag. I’m checking bounded ingress buffering at the socket boundary and awaited queue offers at the async session boundary, including cancellation and connection reuse.@neriousy, please flag if you already have a fix underway; I’m preparing a focused patch and regression evidence for this issue. This work is AI-assisted.
rekram1-node commentedon Sep 22, 2026
Fixed by #50026 and released in v2.0.11. The two fail-on-full 128-frame WebSocket ingress queues were replaced with unbounded handoff queues, with a regression test covering a synchronous 1,500-frame burst. Closing as fixed.