test(snapshots): pin dev_engines_runtime_pnpm11 to the seeded default Node version - #2390
Merged
Merged
Conversation
… Node version The fixture pinned devEngines node 22.22.2, the only pin in the suite that the CI runtime seed does not carry, so the step downloaded Node.js from nodejs.org inside its 60s budget. Connections from the Windows runner to nodejs.org stall intermittently since 2026-08-08, the shared HTTP client's 2-minute request timeout outlives the step budget, and the -s flag keeps the step silent, so the case failed with an empty 60s timeout across branches (e.g. runs 31302523708, 31303209316). Pin 22.18.0 like the pnpm10 sibling. #1289 picked 22.22.2 only as the then-latest 22.x above vp's minimum, and the snapshot redacts the printed version to <version>, so no assertion changes; the case still verifies devEngines.runtime is honored under pnpm 11.
✅ Deploy Preview for viteplus-preview canceled.
|
wan9chi
approved these changes
Aug 10, 2026
fengmk2
added a commit
that referenced
this pull request
Aug 11, 2026
Two snapshot cases intermittently fail the Windows leg with "timed out after 60s" and empty partial output (run 31453833634, attempts 2 and 4; same stall class as #2390): - migration_eslint: the fixture has no Node version pin, so the global vp resolves "latest LTS" through a nodejs.org/dist/index.json fetch before it spawns node and prints anything. Each case runs in a fresh VP_HOME and the CI runtime seed carries no index cache, so every such case fetches the index, and a stalled connection spends the whole 60s step budget with no output. - command_cache_bun: the case provisions bun@1.3.11 into its fresh VP_HOME, and a stalled tarball download holds the request for vp's full download timeout (10 minutes since #2386), so the retry never gets a chance inside the step budget. Two fixes: - Warm the version index cache in the snapshot jobs' prewarm step with `vp env list-remote`, so `node/index_cache.json` lands in the seeded js_runtime dir. nodejs.org serves the index with a one-hour max-age, which covers the whole suite, and vp falls back to an existing cache when a later fetch fails. - Set VP_DOWNLOAD_TIMEOUT=30 (the #2386 knob) in every case's env in the runner, so a stalled runtime or package-manager download fails fast enough for vp's retry to finish inside the 60s step budget. Healthy CI downloads take about a second. Verified with `cargo check -p vp_cli_snapshots --tests` plus local runs of command_cache_bun and dev_engines_runtime_pnpm10 (both pass; the installed vp 0.2.8 ignores the unknown env var, while CI builds vp from HEAD where the cap is active). migration_eslint needs the JS dist that a fresh worktree lacks, so CI covers that case. Claude-Session: https://claude.ai/code/session_015ALfSFSa1Q2BN198bkDbpr
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Since 2026-08-08 the Windows PTY snapshot leg fails intermittently on
dev_engines_runtime_pnpm11: thevp dlx -s print-current-versionstep times out after 60s with empty output (13+ runs across branches, main included, e.g. run 31302523708). The fixture pinned devEngines node22.22.2, the only pin in the suite that the CI runtime seed does not carry, so the step had to download Node.js from nodejs.org inside its 60s budget. Connections from the Windows runner to nodejs.org stall intermittently, and the shared HTTP client's 2-minute request timeout (see #2386) outlives the step budget, so a stalled attempt can neither fail nor retry in time. The siblingdev_engines_runtime_pnpm10pins the seeded default22.18.0and passed in ~2s in the same failed runs, which clears the npm registry path and isolates the stall to nodejs.org.Pin the pnpm11 fixture to
22.18.0as well. The22.22.2pin carried no assertion value: #1289 picked it as the then-latest 22.x above vp's minimum, and the snapshot redacts the printed version to<version>. The case still verifies that vp honorsdevEngines.runtimeunder pnpm 11. Verified withcargo test -p vp_cli_snapshots --test cli_snapshots -- dev_engines_runtime_pnpm11(passes in 6s, no snapshot drift).