[Marcus Lagergren (lagergren)]

Fixes the "Client is not running and can't be stopped" part of #1307.

Problem

When initialization fails, the catch in BaseLanguageClient.initialize calls void this.stop(): when initializationFailedHandler returns false, when the user declines a retry, and in the default case. The client is still in ClientState.Starting at that point, so shutdown throws Client is not running and can't be stopped. It's current state is: starting. Nothing awaits that promise, so the rejection is unhandled. VS Code reports it as an unhandled error (with telemetry, as #1307 describes), and the only way an extension can avoid it is to override stop() and catch every rejection, which also hides real stop failures.

Change

The three calls go through a small stopAfterFailedInitialize() that still calls stop() but handles its rejection, the same way handleConnectionError already handles the stop() it starts: logged with this.error('Stopping server failed', error, false), without a notification.

The client still calls stop(). In my comment on #1307 I suggested releasing the connection without going through stop(), but stop() is what lets subclasses clean up: the Node client's shutdown override terminates the server process in its finally, even though the base shutdown refuses a client that is still starting. Skipping stop() would leave a server that refused initialization running.

Related issues and pull requests

None of these covers this rejection:

• Catching unhandled exceptions when starting language server by LanguageClient #1307 also lists Pending response rejected since connection got disposed. That is the other initialization failure, where the connection closes during initialize. Preserve the startup promise when initialization loses its connection #1867 (merged) makes it reach the caller of start(), and its regression test stubs stop() precisely because of the separate rejection fixed here.
• client: reject start() if server process exits before connecting on pipe/socket transport #1862 and Close pipe/socket transport server when the language server process fails to start #1863 (merged) handle a server process that exits before connecting, or fails to spawn, on pipe and socket transports. That happens before initialize runs.
• Don't rely on Promise.prototype.finally when starting or stopping the client #1895 (open) rewrites shutdown's promise chain without Promise.prototype.finally for finally is not a function error hit with _getServerWorkingDir #1653. It does not change when stop() is called after a failed initialization or who handles its result. This change does not touch shutdown, so the two do not conflict.
• Treat connection close during stop() as handled #1782 (open) treats a connection close during stop() as handled, for a client that is already stopping.
• Improve error handling. #1310 (closed) changed the messages logged for connection errors.
• client.needsStop() and client.stop() disagree on whether it's valid to call stop() #1559 (open) is about needsStop() and stop() disagreeing. It is related: a later stop() or dispose() on a client whose start failed still rejects, because the client is not running. This change leaves that, and the base shutdown's refusal to stop a starting client, as they are.
• Language Client to should log stderr on launch failures #1185 and Allow clients of the LSP library to capture all errors and show customized / localized message. #1262 (open) ask for the server's stderr on launch failures and for customizable error messages; they are about reporting, not this rejection.

Tests

A refused initialization stops the client without an unhandled rejection (in Server tests) starts a client against a new failInitializeServer, which answers initialize with an error but keeps running, so the client still owns a live connection. It checks that start() rejects with the server's error, that stop() is still called once and the server process is ended (the client reaches Stopped when its connection closes), and that no rejection is left unhandled.

Validation

On macOS ARM64 with Node.js 24.21.0 and VS Code Insiders 1.143.0 (a0c652031362):

• npm run compile passed.
• npm --prefix client run lint and npm --prefix client-node-tests run lint passed.
• The complete client-node-tests editor suite passed: 215 tests. Without the change to client.ts, only the new test fails, with the unhandled Client is not running and can't be stopped. It's current state is: starting rejection; unchanged main passes its 214.
• git diff --check passed.

[Marcus Lagergren (lagergren)]

@microsoft-github-policy-service agree company="xtclang.org"

[Copilot]

🔵 Needs a closer look

It modifies the core client lifecycle/async rejection-handling state machine of a widely-depended-upon library, which warrants final human sign-off despite being small and well-tested.

No open issues 🎉

What changed in this PR

This PR fixes an unhandled promise rejection that occurs when a language server refuses initialization. In BaseLanguageClient.initialize, the catch block previously called void this.stop() in three places (when initializationFailedHandler returns false, when the user declines a retry, and in the default case). Because the client is still in ClientState.Starting, the base shutdown rejects with "Client is not running and can't be stopped", and since nothing awaited the promise, VS Code surfaced it as an unhandled error (with telemetry, per #1307). The fix routes all three calls through a new private stopAfterFailedInitialize() helper that still calls stop() (preserving subclass cleanup such as the Node client terminating the server process) but handles the rejection by logging it without a notification — mirroring the existing pattern in handleConnectionError.

Changes:

• Added stopAfterFailedInitialize() to handle stop()'s rejection after a failed initialization, replacing the three void this.stop() calls.
• Added a failInitializeServer test server that refuses initialize but keeps its connection alive.
• Added an integration test asserting start() rejects, stop() is called once, the client reaches Stopped, and no rejection is left unhandled.

File	Description
client/​src/​common/​client.ts	Introduces stopAfterFailedInitialize() and wires it into the three failed-initialization paths so the stop() rejection is logged instead of left unhandled.
client-node-tests/​src/​servers/​failInitializeServer.ts	New test server that returns a ResponseError<InitializeError> from onInitialize while keeping the connection open.
client-node-tests/​src/​integration.test.ts	New test verifying a refused initialization stops the client with no unhandled rejection.

_{Review effort: Balanced}

[Copilot]

🟢 Approval recommended

It is a small, focused rejection-handling fix that mirrors an established in-file pattern and is covered by a targeted regression test, with no identified correctness, API, or convention issues.

No open issues 🎉

_{Review effort: Balanced}

[Copilot]

🟢 Approval recommended

The change is minimal, mirrors an existing handled-stop() pattern exactly, and is backed by a focused regression test that I traced end-to-end without finding any issues.

No open issues 🎉

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

Although I found no issues, the change affects the client lifecycle/initialization error-handling path, so final human review is warranted before approval.

Wait — let me correct that assessment line to match my actual finding.

No open issues 🎉

_{Review effort: Balanced}