Repository navigation
prevent SSE event streams from unbounded memory growth #31087
Description
## Description
Long-running sessions can make the opencode server worker grow memory until it becomes unresponsive.
I reproduced this while resuming an existing session and sending `continue`. A fresh session did not show the same behavior. During the bad run, the worker process reached about 9.5GB RSS:
```text
bun run --cwd packages/opencode --conditions=browser src/index.ts .The likely cause is the SSE event stream buffering events without a bound. On upstream/dev, packages/opencode/src/server/routes/instance/httpapi/handlers/event.ts uses:
Queue.unbounded<EventV2.Payload>()and packages/opencode/src/server/routes/instance/httpapi/handlers/global.ts uses Stream.callback(...) for global events.
If the client is slow, disconnected, or cannot consume events fast enough during a long task, these event streams can retain too many queued events. The instance event stream also queues events before filtering them by instance/workspace.
Expected behavior: slow SSE consumers should not be able to grow server memory without limit. Older progress events can be dropped under backpressure as long as task execution and final state are unaffected.
Plugins
None relevant.
OpenCode version
upstream/dev as of commit 1399323b78a04229d9bfe00c7436d7f41770fda8.
Steps to reproduce
- Start opencode from the repo root:
bun dev .- Open or resume a long-running session that emits many task/tool/progress events.
- Send
continuerepeatedly or let the session run for a long time. - Watch the worker process RSS.
Expected: memory should plateau or fluctuate within a bounded range.
Actual: memory can keep growing until the worker becomes unresponsive.
Screenshot and/or share link
N/A
Operating System
Windows 11
Terminal
Windows Terminal / PowerShell
Activity
github-actions commentedon Jun 6, 2026
This issue doesn't fully meet our contributing guidelines.
What needs to be fixed:
Please edit this issue to address the above within 2 hours, or it will be automatically closed.
This issue might be a duplicate of existing issues. Please check:
If you believe this was flagged incorrectly, please let a maintainer know.
github-actions commentedon Jun 6, 2026
Thank you for updating the issue! It now includes all the required information — a clear description, steps to reproduce, version details, and system info. Everything looks good.
github-actions commentedon Aug 6, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
qvkap commentedon Sep 12, 2026
For anyone running into severe SSE event stream memory ballooning as described here:
I created an experimental personal fork with workaround bounds: https://github.com/qvkap/opencode-clean
Disclaimer:
Mitigation applied for this issue:
In
packages/opencode/src/server/routes/instance/httpapi/handlers/event.ts,Queue.unbounded<EventV2.Payload>()was replaced withQueue.sliding<EventV2.Payload>(1_000)to prevent the worker process from accumulating gigabytes of unconsumed events when downstream consumers lag. Additional LRU caps (MAX_DIAGNOSTICS_FILES = 5_000,MAX_OPEN_FILES = 1_000) were placed on the LSP client state.Under moderate single-session use this prevents the worker from spiking to 9+ GB as quickly, though long-running heavy sessions will still eventually require restarting until a proper runtime-level fix lands upstream.