Repository navigation
Flake: doctor-codelldb-version.test.ts on windows-latest fails with a bare "Command failed" — the test hides the CLI's exit code and stderr #1098
Description
Seen on windows-latest, 2026-11-06, the first re-run of PR #1096's third CI run (https://github.com/debugmcp/mcp-debugger/actions/runs/42243900052, job 127989677607): tests/integration/cli/doctor-codelldb-version.test.ts (#1066's test, merged in #1092 the day before) failed its "reads the raw VSIX manifest" case with nothing but
Error: Command failed: C:\hostedtoolcache\windows\node\22.23.4\x64\node.exe C:\Users\RUNNER~1\AppData\Local\Temp\doctor-codelldb-cuu63h\cli.mjs doctor rust --json --timeout 60000
Everything else passed (440 files, 8,317 tests). The same case passed in that PR's three earlier Windows runs and in #1092's own CI; the failing job ran 19 min against the usual 14–16, so the runner was loaded. Nothing in #1096 touches the doctor or CodeLLDB.
Two things worth doing, both small:
- The test swallows the CLI's output:
execFilerejects with "Command failed" and the assertion shows neither the exit code nor stderr, so the run cannot say whether a probe timed out, the VSIX extraction was slow, ordoctor rustreported an unhealthy toolchain and exited non-zero. Attacherror.stdout/error.stderr(and the exit code) to the failure message. - Once the cause is visible, decide whether the 60 s
--timeoutthe test passes (added in fix(codelldb): read raw VSIX version metadata #1092 because the Windows probes are slow) needs headroom on a loaded runner, or whether the case should assert on the JSON even when the exit code is non-zero (the manifest read is what it tests, not the toolchain's health).
Environment: windows-latest, Node 22.23.4, the full build-and-test integration run as the load.
Activity
gezerui888 commentedon Nov 6, 2026
I'll add the subprocess diagnostics and regression coverage, then open a PR shortly.
debugmcpdev commentedon Nov 7, 2026
Closed by #1099 (merged, thanks @gezerui888):
doctorRustnow rethrows the subprocess failure with the exit code, signal,killedflag, stdout and stderr attached and the original error as the cause, pinned by three regression cases.What the original failure most likely was, now that the shape is legible: the bare message ended in an empty stderr line (Node's
execFileappends stderr toCommand failed: <cmd>), so the CLI exited non-zero with nothing on stderr. That fits a slowcargo -vVon the loaded runner: the rust probe times out, the row's verdict isbroken(gating),doctorexits 1 with the JSON report on stdout, and the old helper threw that report away. The next sighting will print it (probe.timedOut,durationMson the rust row).Step 2 of this ticket — more probe budget, or asserting on the report regardless of the exit code (the manifest read is what the test checks, not the toolchain's health) — waits for that measurement. If the case fails again, comment the new output here, as #963 carries its sightings.