fix(server): harden managed LSP probing and timeouts on Windows

A run of cross-language smoke tests (python, go, rust, vue) on a real
Windows host turned up three classes of failures that all looked like
"LSP unavailable" / "request timed out" but actually pointed at three
different gaps in our probe + timeout logic. Fix them together so the
Install / Retry flow tells the user something true.

- `resolveManagedPythonCommand` now actively probes `<candidate>
  --version` on win32. The zero-byte Microsoft Store app execution
  aliases at `%LOCALAPPDATA%\Microsoft\WindowsApps\python(3).exe` pass
  `where.exe` but silently exit when invoked; before this change the
  install would crash opaquely at `python -m venv ...`. Now the prereq
  check rejects the stub and the UI shows `missing_prerequisite:
  python3, python`.
- `LspToolManager.resolve` runs the same `--version` probe before
  accepting a system-PATH command on win32. This handles the
  symmetric case for rust-analyzer: `~/.cargo/bin/rust-analyzer.exe`
  is a rustup proxy that prints "Unknown binary 'rust-analyzer.exe'"
  to stderr and exits when the `rust-analyzer` rustup component is
  not installed. Before this fix the manager picked the broken proxy
  as the system source, never fell through to the managed download,
  and waited for an initialize response that never came.
- `LspSession` now distinguishes `initializeTimeoutMs` (default
  `requestTimeoutMs * 10`, raised to 60_000 in `server.ts`) from
  `requestTimeoutMs` (raised from 2_000 to 8_000). rust-analyzer's
  `initialize` returns within ~70ms but background workspace indexing
  can take 25s on a real repo; the single 2-second budget would kill
  the child mid-init on cold start and never recover. Hover /
  definition keep the short fail-fast budget so the editor's
  "Loading..." popup doesn't linger when the server is wedged.

Adds 11 unit tests covering the stub rejection paths and the
initialize-vs-request timeout split, plus a `lsp-test/` directory of
single-file fixtures (probe.{py,go,rs,vue}) for repeating the same
smoke check by hand. Files an issue at
`docs/issue/rust-analyzer-indexing-no-progress-feedback.md` describing
the remaining UX gap — rust-analyzer silently returns `null` for
hover/definition during its first ~25s of indexing, and we don't yet
surface its `$/progress` notifications in the LSP status notice.

Test sweep on Windows host: 16 server LSP test files, 118 passed + 3
POSIX-only skipped.

Author: pallyoung

.gitignore

@@ -68,3 +68,8 @@ tsconfig.tsbuildinfo
 
 # Stitch design files
 .stitch/
+
+# Rust build artefacts (from lsp-test/ fixture or any ad-hoc cargo)
+target/
+Cargo.lock
+

docs/issue/rust-analyzer-indexing-no-progress-feedback.md

@@ -0,0 +1,66 @@
+# rust-analyzer 启动期间 hover/definition 静默无响应，UI 无进度反馈
+
+## 标题
+
+`feat(web): surface rust-analyzer indexing progress in the LSP status notice`
+
+## 问题描述
+
+打开第一个 `.rs` 文件时，rust-analyzer 会进入 `PrimeCaches` 阶段对工作区做初始化索引。这个阶段在 coder-studio 仓库根（中等仓库 + 大量 `node_modules`）下实测**会持续 ~25 秒**。
+
+期间：
+
+- `initialize` LSP 请求几十毫秒就返回（rust-analyzer 设计上立刻确认 capabilities，workspace 加载是异步的）
+- 我们的 `LspManager.ensureSession` 拿到 `summary.status === "ready"`，前端把 hover/definition provider 都注册好
+- 但用户**任何** hover/definition 请求都会被 rust-analyzer **立刻返回 `null`**——不是 hang、不是 timeout，而是它故意在 indexing 期间不给语义答案
+- Monaco 拿到 null 就什么都不显示
+- 用户感受：开了 `.rs` 文件之后随便点点都"完全没反应"，像 LSP 没起来
+
+25 秒后 rust-analyzer 发 `$/progress { kind: "end" }` 通知，从此 hover 正常工作。但**这中间的等待期对用户完全不可见**。
+
+## 复现步骤
+
+1. 干净环境，无 rust-analyzer 缓存。
+2. 在 coder-studio 仓库根新建 `Cargo.toml` + `probe.rs`（最小 bin 项目即可）。
+3. 重启 dev server，让 LSP 会话从干净状态启动。
+4. 浏览器中打开 `probe.rs`，立刻 hover 任一标识符。
+5. 观察前 ~25 秒所有 hover/definition/references 都没反应。
+
+可以用 `scripts/probe-rust.mjs probe.rs` 直接复现 ——
+它会同时记录 initialize 用时、首次 hover 响应、`$/progress end` 用时。
+
+## 实际行为
+
+- 前 25 秒：hover 返回 null，UI 安静
+- 之后：hover 工作，但用户多半已经放弃尝试了
+
+## 桌面终端对比
+
+VS Code 的官方 rust-analyzer 扩展会在 status bar 上显示
+`rust-analyzer: indexing X/Y` 进度条；Helix 会在底部状态栏显示同样信息。两者都监听 rust-analyzer
+的 `$/progress` LSP 通知。
+
+我们目前没监听任何 LSP 进度通知。
+
+## 已确认事实
+
+- `initialize` 响应快（~70ms 量级，与 indexing 解耦）
+- rust-analyzer 通过标准 LSP `$/progress`
+  notification 通报进度，token 是 `"rustAnalyzer/Indexing"` 或类似
+- `LspSession`（`packages/server/src/lsp/session.ts`）目前没有 `connection.onNotification("$/progress", ...)`
+  处理器
+- 前端 `LspStatusNotice` 目前只有 ready / installing / failed / disabled 四种状态显示
+
+## 后续排查方向
+
+- **server**：`LspSession` 监听 `$/progress` 通知，把 `WorkDoneProgressBegin` /
+  `WorkDoneProgressReport` / `WorkDoneProgressEnd` 转成 `lsp.progress.updated` 事件
+  via `eventBus`
+- **core / shared**：在 `LspEnsureSessionResult` 或独立 `LspProgress` 类型里加一个 "indexing" 状态
+- **web**：`LspStatusNotice` 渲染 "Indexing 12 / 47 …" 或简单的 spinner + percentage
+- 范围只对 rust-analyzer + 任何主动发 `$/progress` 的 server（pylsp、gopls 通常不发）
+
+## 临时缓解
+
+- 文档里告诉用户："首次打开 `.rs` 文件需要等 ~30s 完成索引"
+- 或检测 rust-analyzer 没回有效 hover 时，在编辑器里给一个 transient toast 提示

lsp-test/Cargo.toml

@@ -0,0 +1,9 @@
+[package]
+name = "probe"
+version = "0.0.0"
+edition = "2021"
+publish = false
+
+[[bin]]
+name = "probe"
+path = "probe.rs"

lsp-test/README.md

@@ -0,0 +1,29 @@
+# LSP smoke-test fixtures
+
+A small set of single-file projects used to verify each managed LSP works end-to-end against the editor (hover / definition / references / diagnostics). Each file has a TYPE ERROR at the bottom on purpose so the diagnostic provider also gets exercised.
+
+| File | Language server | What to verify |
+| --- | --- | --- |
+| `probe.vue` | `@vue/language-server` (Volar 3) + `typescript-language-server` companion | hover on `ref`/`computed`/`defineProps`, F12 to `Props`, red squiggle on the type error |
+| `probe.py` | `python-lsp-server` (pylsp, managed) | hover on `multiply_by`/`Greeter`, F12 across functions, pyflakes-level diagnostic |
+| `probe.go` | `gopls` (managed) | hover on `MultiplyBy`/`Greeter.Greet`, F12 across functions, type-mismatch diagnostic |
+| `probe.rs` + `Cargo.toml` | `rust-analyzer` (system rustup component or managed download) | hover on `multiply_by`/`Greeter`/`greet`, F12 across functions, type-mismatch diagnostic |
+
+## Why a `Cargo.toml`
+
+Unlike the other servers, **rust-analyzer refuses to provide semantic info for `.rs` files that don't belong to a Cargo project**. The minimal `Cargo.toml` in this directory declares `probe.rs` as a bin so rust-analyzer treats the directory as a workspace.
+
+> rust-analyzer also takes ~25s on cold start to finish `PrimeCaches` indexing, during which all hover/definition requests silently return `null`. See `docs/issue/rust-analyzer-indexing-no-progress-feedback.md`.
+
+## How to run
+
+1. Open coder-studio in the editor (dev or built).
+2. Open any file in this directory.
+3. First open triggers the LSP install if needed — look for the `Install` button in the inline notice.
+4. Once the notice disappears, exercise the four LSP features listed above.
+
+For protocol-level debugging without the editor in the loop, see `scripts/probe-vue-bridge.mjs` and `scripts/probe-rust.mjs` — they spawn the language server directly and assert specific LSP responses.
+
+## Cleanup
+
+These fixtures are intentionally checked in so a new contributor can repeat the same smoke check on day one. Feel free to leave them in place; they don't affect any production build.

lsp-test/probe.go

@@ -0,0 +1,45 @@
+// Quick LSP smoke probe for gopls.
+//
+// Try in the editor once this file is open:
+//
+//  1. Hover over `numbers`, `total`, `MultiplyBy`, `Greeter`, `Greet` —
+//     each should show its inferred Go signature with package context.
+//  2. Ctrl-Click (or F12) on `MultiplyBy` inside `ComputeTotal` to jump
+//     to its definition.
+//  3. Shift+F12 on `Greet` to see references.
+//  4. The line marked `// TYPE ERROR` should get a gopls diagnostic
+//     (passing a string where an int is expected).
+//
+// Note: gopls expects a real module to fully analyze; we declare a
+// throwaway one here so the file is self-contained.
+
+package main
+
+import "fmt"
+
+func MultiplyBy(value, factor int) int {
+	return value * factor
+}
+
+func ComputeTotal(numbers []int, factor int) int {
+	total := 0
+	for _, n := range numbers {
+		total += MultiplyBy(n, factor)
+	}
+	return total
+}
+
+type Greeter struct {
+	Name string
+}
+
+func (g Greeter) Greet() string {
+	return fmt.Sprintf("Hello, %s!", g.Name)
+}
+
+func main() {
+	fmt.Println(ComputeTotal([]int{1, 2, 3}, 4))
+	fmt.Println(Greeter{Name: "Vue"}.Greet())
+	// TYPE ERROR: passing a string where an int is expected.
+	fmt.Println(MultiplyBy("not a number", 2))
+}

lsp-test/probe.py

@@ -0,0 +1,41 @@
+"""Quick LSP smoke probe for python-lsp-server (pylsp).
+
+Try the following in the editor once this file is open:
+
+1. Hover over `numbers`, `total`, `multiply_by`, `Greeter`, `greet` —
+   each should show its inferred type / signature.
+2. Ctrl-Click (or F12) on `multiply_by` inside `compute_total` to jump
+   to its definition.
+3. Shift+F12 on `greet` to see references.
+4. The line marked `# TYPE ERROR` should get a pylsp diagnostic
+   (pylsp ships with pyflakes / pycodestyle by default; the call passes
+   a string to a parameter typed as `int`).
+"""
+
+from dataclasses import dataclass
+
+
+def multiply_by(value: int, factor: int) -> int:
+    return value * factor
+
+
+def compute_total(numbers: list[int], factor: int) -> int:
+    total = 0
+    for n in numbers:
+        total += multiply_by(n, factor)
+    return total
+
+
+@dataclass
+class Greeter:
+    name: str
+
+    def greet(self) -> str:
+        return f"Hello, {self.name}!"
+
+
+if __name__ == "__main__":
+    print(compute_total([1, 2, 3], 4))
+    print(Greeter("Vue").greet())
+    # TYPE ERROR: passing a string where an int is expected.
+    print(multiply_by("not a number", 2))

lsp-test/probe.rs

@@ -0,0 +1,44 @@
+//! Quick LSP smoke probe for rust-analyzer.
+//!
+//! Try in the editor once this file is open:
+//!
+//!   1. Hover over `numbers`, `total`, `multiply_by`, `Greeter`, `greet` —
+//!      each should show its inferred Rust type or signature.
+//!   2. Ctrl-Click (or F12) on `multiply_by` inside `compute_total` to jump
+//!      to its definition.
+//!   3. Shift+F12 on `greet` to see references.
+//!   4. The line marked `// TYPE ERROR` should get a rust-analyzer
+//!      diagnostic (passing a `&str` where `i64` is expected).
+//!
+//! Note: rust-analyzer is happiest inside a Cargo workspace, so a few
+//! features may behave slightly differently here than they would in a
+//! real crate, but hover / definition / references still work.
+
+fn multiply_by(value: i64, factor: i64) -> i64 {
+    value * factor
+}
+
+fn compute_total(numbers: &[i64], factor: i64) -> i64 {
+    let mut total = 0;
+    for n in numbers {
+        total += multiply_by(*n, factor);
+    }
+    total
+}
+
+struct Greeter {
+    name: String,
+}
+
+impl Greeter {
+    fn greet(&self) -> String {
+        format!("Hello, {}!", self.name)
+    }
+}
+
+fn main() {
+    println!("{}", compute_total(&[1, 2, 3], 4));
+    println!("{}", Greeter { name: "Vue".to_string() }.greet());
+    // TYPE ERROR: passing a &str where i64 is expected.
+    println!("{}", multiply_by("not a number", 2));
+}

lsp-test/probe.vue

@@ -0,0 +1,15 @@
+<script setup lang="ts">
+import { computed, ref } from "vue";
+
+const count = ref(0);
+const doubled = computed(() => count.value * 2);
+
+interface Props {
+  label: string;
+}
+const props = defineProps<Props>();
+</script>
+
+<template>
+  <button @click="count++">{{ props.label }} {{ doubled }}</button>
+</template>

packages/server/src/__tests__/fixtures/fake-lsp-server.js

@@ -16,9 +16,10 @@ const connection = createMessageConnection(
 const docs = new Map();
 const exitAfterInitMs = Number(process.env.CODER_STUDIO_FAKE_LSP_EXIT_AFTER_INIT_MS ?? "0");
 const hoverDelayMs = Number(process.env.CODER_STUDIO_FAKE_LSP_HOVER_DELAY_MS ?? "0");
+const initDelayMs = Number(process.env.CODER_STUDIO_FAKE_LSP_INIT_DELAY_MS ?? "0");
 const stderrOnInit = process.env.CODER_STUDIO_FAKE_LSP_STDERR_ON_INIT ?? "";
 
-connection.onRequest("initialize", () => {
+connection.onRequest("initialize", async () => {
   if (stderrOnInit) {
     process.stderr.write(`${stderrOnInit}\n`);
   }
@@ -28,6 +29,13 @@ connection.onRequest("initialize", () => {
     timer.unref?.();
   }
 
+  if (initDelayMs > 0) {
+    await new Promise((resolve) => {
+      const timer = setTimeout(resolve, initDelayMs);
+      timer.unref?.();
+    });
+  }
+
   return {
     capabilities: {
       definitionProvider: true,

packages/server/src/lsp-tools/definitions.test.ts

@@ -0,0 +1,92 @@
+import { describe, expect, it, vi } from "vitest";
+import { resolveManagedPythonCommand } from "./definitions.js";
+
+describe("resolveManagedPythonCommand", () => {
+  it("returns the first available candidate on POSIX hosts without probing", async () => {
+    const commandExists = vi.fn(async (cmd: string) => cmd === "python3");
+    const runCommand = vi.fn();
+
+    await expect(
+      resolveManagedPythonCommand(commandExists, "linux", runCommand as never)
+    ).resolves.toBe("python3");
+    // POSIX hosts do not have Microsoft Store stubs; the helper must NOT
+    // execute the candidate just to check the version.
+    expect(runCommand).not.toHaveBeenCalled();
+  });
+
+  it("returns null when no candidate is on PATH", async () => {
+    await expect(
+      resolveManagedPythonCommand(
+        vi.fn(async () => false),
+        "linux"
+      )
+    ).resolves.toBeNull();
+  });
+
+  it("on Windows, rejects a candidate whose `--version` prints nothing (Store stub)", async () => {
+    // Windows ships zero-byte App Execution Aliases for `python` /
+    // `python3`. `where.exe` reports them as present, but invoking them
+    // silently exits with empty stdout/stderr because Python is not
+    // actually installed.
+    const commandExists = vi.fn(async () => true);
+    const runCommand = vi.fn(async () => ({ stdout: "", stderr: "" }));
+
+    await expect(
+      resolveManagedPythonCommand(commandExists, "win32", runCommand)
+    ).resolves.toBeNull();
+    expect(runCommand).toHaveBeenCalledTimes(2);
+    expect(runCommand).toHaveBeenCalledWith(
+      "python3",
+      ["--version"],
+      expect.objectContaining({ windowsHide: true })
+    );
+    expect(runCommand).toHaveBeenCalledWith(
+      "python",
+      ["--version"],
+      expect.objectContaining({ windowsHide: true })
+    );
+  });
+
+  it("on Windows, accepts a candidate whose --version prints output on stdout", async () => {
+    const commandExists = vi.fn(async () => true);
+    const runCommand = vi.fn(async () => ({ stdout: "Python 3.12.0\n", stderr: "" }));
+
+    await expect(resolveManagedPythonCommand(commandExists, "win32", runCommand)).resolves.toBe(
+      "python3"
+    );
+  });
+
+  it("on Windows, accepts a candidate whose --version prints to stderr (older Pythons)", async () => {
+    // Pythons < 3.4 print the version banner to stderr instead of stdout.
+    const commandExists = vi.fn(async () => true);
+    const runCommand = vi.fn(async () => ({ stdout: "", stderr: "Python 2.7.18\n" }));
+
+    await expect(resolveManagedPythonCommand(commandExists, "win32", runCommand)).resolves.toBe(
+      "python3"
+    );
+  });
+
+  it("on Windows, falls through to the next candidate when the first one's probe fails to spawn", async () => {
+    const commandExists = vi.fn(async () => true);
+    const runCommand = vi.fn(async (file: string) => {
+      if (file === "python3") {
+        // simulate spawn failure (file is a stub that can't be executed)
+        throw new Error("spawn python3 ENOENT");
+      }
+      return { stdout: "Python 3.12.0\n", stderr: "" };
+    });
+
+    await expect(resolveManagedPythonCommand(commandExists, "win32", runCommand)).resolves.toBe(
+      "python"
+    );
+  });
+
+  it("on Windows, returns null when both candidates are stubs that print nothing", async () => {
+    const commandExists = vi.fn(async () => true);
+    const runCommand = vi.fn(async () => ({ stdout: "", stderr: "" }));
+
+    await expect(
+      resolveManagedPythonCommand(commandExists, "win32", runCommand)
+    ).resolves.toBeNull();
+  });
+});