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
{{ message }}
Repository navigation
[Bug]: Bash tool hangs on fast-exiting processes and locks database on massive output #21000
OpenCode Backend Bug: Tool Execution Hangs and Event Loop Blockage
Bug Description
The OpenCode backend experiences two severe stability issues when executing the bash tool:
Indefinite Hangs (Ghost Processes): When a fast-exiting command (like jq, echo, or commands that crash instantly) is executed, the session sometimes hangs permanently. The tool remains in the running state in the UI indefinitely, even though the underlying OS process has already terminated.
Event Loop Blockage (database is locked): When a command emits thousands of lines of output very quickly (e.g., npm install, a large grep, or cat on a massive file), the backend Node.js process chokes, leading to SQLiteError: database is locked exceptions. This drops events and causes the session to hit the 15-second heartbeat timeout.
Root Causes
Race Condition in CrossSpawnSpawner:CrossSpawnSpawner relies strictly on the spawn event to resolve the Effect promise. If a process exits so fast that the spawn event is omitted or misordered by the OS/Node bindings, the resume() callback is never called, leaving the execution promise blocked forever.
Synchronous Metadata Writes: The stream processor (Stream.runForEach) invokes ctx.metadata(...) for every single chunk emitted by the process stdout/stderr. This queues thousands of synchronous db.insert().run() calls on the main thread, locking the database and completely starving the event loop. Furthermore, when the process does exit, the background stream fiber is instantly interrupted, which silently drops any output chunks still buffered in memory.
Steps to Reproduce
Issue 1: Indefinite Hangs
Dispatch multiple fast-exiting tools at once, or run a single incredibly fast tool like jq '{test: 1}'.
Notice that randomly, the UI gets stuck on "running command".
Check ps aux | grep jq — the process is dead, but the backend is still waiting.
Issue 2: DB Locking and Event Loop Starvation
Run a command that outputs massive amounts of text instantly, e.g., cat /dev/urandom | head -n 100000 | base64 or find /.
Watch the logs fill with unhandled SQLiteError: database is locked.
The UI will eventually stall and the session will crash or timeout.
Expected Behavior
Fast-exiting processes should reliably resolve their execution promise regardless of event ordering.
High-volume output commands should throttle their metadata updates (e.g., every 250ms) to avoid locking the single-writer SQLite database and choking the Node event loop.
The stream fiber should fully drain its buffered output before completing the tool execution, ensuring no trailing output is truncated.
database is locked #19521: Database is locked — overlaps with the SQLite lock contention / event loop starvation symptom described here
Please review those issues and, if your report covers the same root cause or adds new information, consider commenting there instead of opening a new issue. If your report is genuinely distinct (e.g., the race condition in spawn event ordering is a separate root cause from the background child pipe issue in #20902), please clarify that distinction so maintainers can track them separately.
Activity
github-actions commentedon Apr 4, 2026
This issue might be a duplicate of existing issues. Please check:
Please review those issues and, if your report covers the same root cause or adds new information, consider commenting there instead of opening a new issue. If your report is genuinely distinct (e.g., the race condition in spawn event ordering is a separate root cause from the background child pipe issue in #20902), please clarify that distinction so maintainers can track them separately.
t2174: feat(opencode): weekly DB maintenance routine (r913) for SQLit…
t2174: feat(opencode): weekly DB maintenance routine (r913) for SQLit…
t2174: feat(opencode): weekly DB maintenance routine (r913) for SQLit…
github-actions commentedon Jul 4, 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.