| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
Thanks for your contribution! This PR doesn't have a linked issue. All PRs must reference an existing issue. Please:
See CONTRIBUTING.md for details. |
Sorry, something went wrong.
|
The following comment was made by an LLM, it may be inaccurate: Based on my search, I found several related PRs that address similar issues with process management and cleanup: Potentially Related PRs:
These PRs appear to be addressing the same class of issues (process accumulation, memory leaks, signal handlers, and graceful shutdown) across different modes of the application. PR #14092 seems most relevant as it specifically targets web/serve shutdown issues. |
Sorry, something went wrong.
|
Thanks for updating your PR! It now meets our contributing guidelines. 👍 |
Sorry, something went wrong.
…lation
In `opencode web` mode, switching projects creates new Instance entries (each
spawning MCP server child processes) that are never cleaned up. Unlike the TUI
which calls shutdown()/disposeAll() on exit, the web command blocks forever
with `await new Promise(() => {})` and never reaches its `server.stop()` call.
This causes unbounded process growth — each project switch leaks ~200MB of MCP
server processes (linear, notion, etc.) that persist for the lifetime of the
web server.
Fix:
- Add signal handlers (SIGINT, SIGTERM, SIGHUP) to the web command that call
Instance.disposeAll() with a 5s timeout before exiting
- Add idle eviction to Instance: track last access time per directory, sweep
every 60s, and dispose instances idle for >5 minutes
- Clean up lastAccess bookkeeping in dispose() and disposeAll()
|
Looks like other PRs that are similar have been merged. Will close this one! |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Issue for this PR
Closes #14091
Type of change
What does this PR do?
Same root cause as #14092 — server.stop() is unreachable dead code after await new Promise(() => {}) in web.ts, and no signal handlers exist. I also added idle eviction of cached Instance entries, which #14092 doesn't cover: without it, each project switch accumulates MCP server processes (~200MB each) for the entire lifetime of the web server, even if those projects are never revisited.
Signal handlers (SIGINT/SIGTERM/SIGHUP) follow the existing worker.ts pattern. Idle eviction sweeps every 60s and disposes instances idle >5 minutes. I didn't touch serve.ts or the SSE cleanup — happy to add those if this gets traction, or #14092 can cover them.
How did you verify your code works?
Ran patched and unpatched instances side by side on the same machine. After switching between 8 projects over ~30 minutes:
bun turbo typecheck (16/16 pass), bun turbo test (1172 pass, 0 fail).
Screenshots / recordings
No UI changes.
Checklist