Memory leak: LSP client diagnostics and files maps not cleared on shutdown #9143

Activity

1. github-actions

   assigned

   rekram1-node

   on Jan 17, 2026
2. github-actions

   added

   perfIndicates a performance issue or need for optimizationIndicates a performance issue or need for optimization

   on Jan 17, 2026
3. github-actions commented on Jan 17, 2026

   

   github-actionsBot

   on Jan 17, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of or closely related to existing memory management issues. Please check:

   • Memory leak: Unbounded caches grow without limit #9140: Unbounded caches cause memory growth over time
   • opencode eating 70gb of memory? #5363: opencode eating 70gb of memory?
   • v1.1.6 still has memory bloat - heap not released + MCP orphan processes #7261: v1.1.6 still has memory bloat - heap not released + MCP orphan processes
   • [FEATURE]: TUI whole and LSP memory limits as part of configuration #8947: [FEATURE]: TUI whole and LSP memory limits as part of configuration

   These issues all address memory retention and cleanup problems in OpenCode, including LSP-related memory leaks. Your proposed fix for clearing diagnostics and files maps in LSPClient.shutdown() is directly addressing part of the root cause identified in #9140 regarding unbounded caches.

   Feel free to ignore if your specific case differs from these.
4. sauerdaniel

   changed the title [-]LSP client diagnostics and files maps not cleared on shutdown[/-] [+]Memory leak: LSP client diagnostics and files maps not cleared on shutdown[/+] on Jan 18, 2026
5. aptor9 commented on Jan 19, 2026

   

   aptor9

   on Jan 19, 2026

   More actions

   This is what I got from claude. Maybe worth a double check?

   Do I need garbage collect diagnostics or paths variables in lsp/client.ts?

   ● Looking at this code, there are two data structures that accumulate state:

   1. diagnostics (line 51) - Map<string, Diagnostic[]> - Stores diagnostics per file path
   2. files (line 135-137) - { [path: string]: number } - Tracks document versions

   Short answer: No, you likely don't need to.

   Here's why:

   1. Lifecycle is tied to the LSP client - Both maps are naturally garbage collected when the client calls shutdown() (line 239-245) and the client object is released.
   2. diagnostics is self-updating - When the LSP server clears diagnostics for a file, it sends an empty array via publishDiagnostics, which updates the map correctly. It's also
      cleared on file open (line 194).
   3. files versioning is needed - The version numbers must persist to correctly distinguish between didOpen vs didChange notifications. Clearing this could cause protocol issues
      if a file is re-opened (version conflicts).
   4. Memory impact is minimal - These store string keys with small values (arrays or numbers). Even with hundreds of files, the memory footprint is negligible.

   When you might want to consider it:

   • If the LSP client lives for extremely long sessions with thousands of unique files being touched
   • If you implement a textDocument/didClose notification (currently missing), you could clean up both maps when a file is explicitly closed

   For typical usage patterns, the current design is fine.
6. sauerdaniel commented on Jan 19, 2026

   

   sauerdaniel

   on Jan 19, 2026

   ContributorAuthor

   More actions

   This was already fixed in commit f936043dd (Jan 15, 2026):

   diagnostics.clear()
   for (const path in files) delete files[path]

   The fix is exactly as proposed in this issue. See: f936043
7. sauerdaniel

   closed this as completedon Jan 19, 2026