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).

Start in main.ts at activate() and inspect how the bootstrap error from spawning the configured server is caught and rethrown. Reproduce the failure with the missing server.path described in the issue, then compare it with the existing stopped or errored server state and retry behavior. Confirm the intended activation outcome with maintainers, since the issue presents two possible fixes rather than one settled change.