VS Code: Stop charging Node startup to the Project Analysis timeout

[assirims]

Fixes #2552.

Problem

Project Analysis in the VS Code extension spawns a fresh Node process per file (os.cpus().length at once) and kills each after 1 s. Every worker first has to boot Node and load the WASM bundle before it reads the file: ~0.45 s on an idle Apple Silicon Mac, ~0.7 s with the formatter enabled. Under any CPU contention most of a large project is reported as "Timed Out". On a 460-template Rails app the count was 452, 238 and 275 on the same tree, tracking machine load rather than the files; the native parser needs at most 24 ms on the largest template.

Change

• analysis-service.ts — the process-level limit becomes a 30 s hang guard (WORKER_TIMEOUT_MS) with a comment on why it must not be tight. The parse itself is already bounded by ParserOptions.timeout (1 s by default), so runaway parses are still caught.
• parse-worker.js — reports timedOut: true when the parse result carries a TIMEOUT_ERROR, and the service maps that to the timeout status. The "Timed Out" group therefore keeps meaning "the parser gave up on this file" rather than "Node did not finish booting".

No new settings, no change to the worker's arguments.

Verification

• With the bundled extension.js patched to the same larger timeout, all 460 files pass Project Analysis on the machine that reported the timeouts.
• node --check on the worker; the TypeScript change is a constant, one option, and one ternary.
• I could not run the monorepo build locally (it needs the native toolchain), so CI is the typecheck here.

🤖 Generated with Claude Code

[Copilot]

🟢 Approval recommended

The changes are small, consistent with existing error-type conventions, and align the timeout status with parser timeouts while avoiding false positives from worker startup latency.

Pull request overview

This PR adjusts the VS Code extension’s Project Analysis worker management so that “Timed Out” reflects parser-level timeouts (via TIMEOUT_ERROR) rather than Node/WASM startup overhead, and increases the process-level timeout to act as a hang guard instead of a tight per-file budget.

Changes:

• Increase the worker process timeout in AnalysisService to a 30s hang guard (WORKER_TIMEOUT_MS) and document why it must be generous.
• Have parse-worker.js surface a timedOut flag when the parse produced a TIMEOUT_ERROR, and map that flag to the timeout status in the service.

File summaries

File	Description
javascript/packages/vscode/src/analysis-service.ts	Raises the exec timeout to a hang guard and maps worker-reported parse timeouts to the timeout file status.
javascript/packages/vscode/src/parse-worker.js	Detects TIMEOUT_ERROR among recursive parse errors and reports timedOut in the worker result JSON.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[marcoroth]

Thanks @assirims!