[Bug] [LSP] MonacoLspClient never disposes its language-feature registrations

Reproducible in vscode.dev or in VS Code Desktop?

• Not reproducible in vscode.dev or VS Code Desktop

Reproducible in the monaco editor playground?

• Not reproducible in the monaco editor playground

Monaco Editor Playground Link

Summary

MonacoLspClient registers Monaco language providers (hover, code-actions, definition, completion, …) through its LspXxxFeature instances when it is constructed, but it exposes no way to release them. The DisposableStore returned by createFeatures() is discarded at the call site, and the class has no dispose() method — so the registrations remain alive in monaco.languages.* for the lifetime of the page even after the underlying transport is closed.

Reproduction

1. Construct new MonacoLspClient(transportA) for some language. Confirm monaco.languages.registerHoverProvider, …registerCodeActionProvider, etc. are now active (empirically: hover a symbol in a matching model; or instrument monaco.languages.register* to count calls).
2. Drop the only reference to the client and close transportA (e.g. transportA.close() on a WebSocketTransport).
3. Construct new MonacoLspClient(transportB) with a fresh transport for the same language. Hover a symbol.

Observed: Monaco aggregates across all registered providers and awaits each one. The first client's providers are still installed; their requests reach LspConnection.server.hover(...) over the closed transport and never resolve. Monaco shows a permanent "Loading…" entry in the hover widget alongside the response from the new client. The code-action lightbulb has the same symptom — stale providers contribute uncancellable pending promises to the aggregated list.

This is a real repro from embedding MonacoLspClient in a React component whose mount/unmount cycle creates and tears down the LSP session.

Root cause

monaco-lsp-client/src/adapters/LspClient.ts:46 — MonacoLspClient.constructor:

this.createFeatures();    // returns IDisposable, value discarded

monaco-lsp-client/src/adapters/LspClient.ts:62-89 — createFeatures():

protected createFeatures(): IDisposable {
    const store = new DisposableStore();
    store.add(new LspCompletionFeature(this._connection));
    // ... 21 more features ...
    return store;
}

Each LspXxxFeature extends Disposable and calls monaco.languages.registerXxxProvider(...) in its constructor, adding the returned disposable to its own internal _store. Disposing the store returned by createFeatures() would cascade through every feature's dispose() → _store.dispose() → every registerXxxProvider disposable. But the store is dropped on the floor, and the class has no dispose() to wire it up.

Fix

MonacoLspClient should implement Disposable.

Why this matters

Any embedder with a component lifecycle (React, Vue, Solid, Lit, …) hits this. Workarounds require monkey-patching the prototype to capture the discarded store, which is not pleasant.

The LSP spec doesn't have an opinion on client teardown — this is purely a Monaco-side hygiene issue.

Monaco Editor Playground Code

Reproduction Steps

No response

Actual (Problematic) Behavior

No response

Expected Behavior

No response

Additional Context

No response