Canary failure: published-artifact smoke (2026-10-20) #968

Activity

1. github-actions

   added

   canary-failureAuto-filed by the canary workflowAuto-filed by the canary workflow

   on Oct 20, 2026
2. debugmcpdev

   added 3 commits that reference this issue on Oct 20, 2026

   ci(canary): give the doctor backend-source step a 120 s probe timeout (…

   ...

   9f3e3b2

   fix(doctor): review follow-ups for #968

   ...

   f0d57fd

   fix(doctor): named languages are probed first and four at a time; the…

   ...

   76f1320
3. debugmcpdev

   closed this as completedin #970on Oct 20, 2026
4. debugmcpdev commented on Oct 20, 2026

   

   debugmcpdev

   on Oct 20, 2026

   Collaborator

   More actions

   Triage: the canary failed one leg, npm default (windows-latest), against the published 0.25.1. The step doctor rust --json --timeout 30000 found rust's probe still running at 30 s. This is the second time the same mechanism has hit this leg. #789 (2026-09-22) was the server's first list_supported_languages timing out at 30 s on 0.24.2.

   What the transcript shows. doctor rust probes all ten adapters at once and only uses rust's result for the exit code. Everything on that runner was slow at the same time:

   Probe	Duration
   ruby	28.9 s
   rust	over 30 s
   go	26.7 s
   java	21.1 s, to report "Java not found"
   dotnet	11.0 s
   cpp	2.6 s
   python	0.7 s, already warmed by the pip step

   The next step on the sibling leg probed every adapter again and finished a whole smoke cycle in 4 s, so the cost is the first run of each toolchain on a fresh VM. This step ran the same published 0.25.1 every week; on Windows it took:

   Date	Step duration
   2026-09-29	5–6 s
   2026-09-30	11–15 s
   2026-10-13	12–27 s
   2026-10-20	36–37 s

   The runner changed, not the code.

   Changes

   • fix(doctor): named languages are probed first and four at a time; the Rust probe is one cargo -vV (#968) #970 (product). doctor probes four languages at a time. Named languages go first, alongside each other only, so a gated verdict never waits on an unrelated toolchain. The report still lists every language in registry order. Rust's probe is now one direct cargo -vV, replacing two shell-spawned cargo --version calls and a rustc -Vv that loads the 183 MB rustc_driver library. Measured on a warm local machine: rust's probe went from 260–300 ms to 45–58 ms, and doctor's wall time grew by about 0.15 s. The server's list_supported_languages and the launch gate use the same validate(), so their first Rust probe is one spawn now too.
   • ci(canary): give the doctor backend-source step a 120 s probe timeout (#968) #971 (canary, merged as 9f3e3b2). The step's timeout is now 120 s. The step checks where CodeLLDB resolves from, and a rust row that timed out has no backend.source to check.

   Verification. I dispatched the npm channel on main after #971 (run 39451675357): all eight legs passed. Windows default asserted platform-package and omit-optional asserted env:CODELLDB_PATH. Their doctor steps took 12 s and 20 s, so that runner would have passed at 30 s too. The run shows the step works, not that the headroom was needed.

   Not measured. I can't reproduce a cold windows-latest VM locally, and the canary installs the published package. So the claim that #970 keeps a named language's probe well under its timeout on a cold runner is inferred. The first weekly run after the next release is the measurement: the Windows doctor step duration and rust's probe.durationMs in a failing transcript.

   Follow-up. #969 covers the rest of the probe inventory: duplicate spawns in Java, Python and Go, five copies of a version-probe helper, stdout read on exit, and the Rust launch path's shell spawns.