A failed server start makes the whole extension fail to activate, which can strand an extension that configured it

rust-analyzer version: 0.3.3041 (9074e9b4c6 2026-09-06)

rustc version: 1.100.0-nightly (e7769602a 2026-08-24)

editor or extension: VS Code, rust-lang.rust-analyzer 0.3.3041

relevant settings: rust-analyzer.server.path, set by another extension via the addConfiguration API

Hi! We maintain an extension that configures rust-analyzer through addConfiguration, and we walked into a state we couldn't get out of. Wanted to write it up, since I think the underlying behaviour is worth a look independent of our setup.

What happens

If the configured server binary can't be spawned (in our case the path to the configured rust-analyzer binary was removed), activate() fails: main.ts catches the bootstrap error, shows a message, and rethrows. VS Code caches activation failures for the life of the extension host, so the extension stays failed until the window is reloaded. Restarting the server isn't enough.

Two things follow from that:

1. Any extension declaring extensionDependencies: ["rust-lang.rust-analyzer"] is taken down too, because VS Code won't activate an extension whose dependency failed. Ours never appears in the extension host's activation list at all.

2. The extension that provided the bad configuration via addConfiguration will not be activated (because of its extensionDependencies declaration), so it cannot repair the bad configuration that would allow the r-a extension to activate.

And because addConfiguration values are persisted in the extension's workspaceState, a path that was valid when it was written gets spawned again on the next launch, before anything has a chance to re-resolve it. In our case a build directory was cleaned, the recorded binary went away, and every subsequent window failed the same way.

Steps to reproduce

1. From any extension, addConfiguration("your.ext", { "server.path": "/tmp/nope/rust-analyzer" }).
2. Reload the window.

rust-analyzer fails to activate. Anything depending on it fails to activate. The value is in workspaceStorage/<hash>/state.vscdb under rust-lang.rust-analyzer, in extensionConfigurations, so it survives restarts, and there's no UI to clear it, since it isn't in settings.json.

Would you take a change here?

Not sure what you'd prefer, so I'd rather ask than send a patch:

• Don't fail activation when only the server failed to start. The extension already models a stopped or errored server (status bar, startServer, restartServer), so activation could succeed with the server in an error state, and a retry wouldn't need a window reload. This seems like the smallest change with the widest benefit, and it doesn't touch the "never silently run a different binary than the one configured" policy at all.

• Optionally, treat an extension-supplied server.path as advisory. Hard-failing on a user's explicit setting makes sense; for an extension-supplied one, warning and falling back might be kinder, since the user can't see or edit it.

Happy to help/do the work here, if it's something I can handle. And happy to be told this is working as intended and we should just stop declaring a hard dependency (which is what I'm planning to do anyway).