test(snapshots): stop Windows network stalls from timing out PTY cases - #2407
Closed
fengmk2 wants to merge 1 commit into
Closed
test(snapshots): stop Windows network stalls from timing out PTY cases#2407fengmk2 wants to merge 1 commit into
fengmk2 wants to merge 1 commit into
Conversation
✅ Deploy Preview for viteplus-preview canceled.
|
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
fengmk2
force-pushed
the
test/deflake-snapshot-network-stalls
branch
from
August 11, 2026 05:23
c6b4207 to
cb0e789
Compare
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
1 participant
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.
Two PTY snapshot cases intermittently fail the Windows leg with "timed out after 60s" and empty partial output:
migration_eslintandcommand_cache_bun(run 31453833634, attempts 2 and 4 red, attempt 5 green with no code change). This is the stall class from #2390: the Windows runner's connections to external hosts stall intermittently, and any step that must fetch from the network inside its 60s budget dies with no output.Where each case stalls:
migration_eslinthas no Node version pin, so the global vp resolves "latest LTS" through anodejs.org/dist/index.jsonfetch before it spawns node and prints anything. Each case runs in a freshVP_HOMEand the CI runtime seed carries no index cache, so every unpinned case fetches the index. A stall there spends the whole step budget before the first byte of output.command_cache_bunprovisionsbun@1.3.11into its freshVP_HOME. A stalled tarball download holds the request for vp's full download timeout (10 minutes since feat(cli): make download timeout configurable and more forgiving #2386), so the in-request retry never fires inside the step budget.Two fixes:
vp env list-remote, sonode/index_cache.jsonlands in the seededjs_runtimedir. 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.VP_DOWNLOAD_TIMEOUT=30(the feat(cli): make download timeout configurable and more forgiving #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 (3 attempts) to finish inside the 60s step budget. Healthy CI downloads take about a second.Verification:
cargo check -p vp_cli_snapshots --testsandcargo fmt --checkpass;command_cache_bunanddev_engines_runtime_pnpm10pass through the runner locally with the new env (the installed vp 0.2.8 ignores the unknown variable; CI builds vp from HEAD where the cap is active).migration_eslintneeds the JS dist build a fresh worktree lacks, so CI covers it.vp env list-remotewas verified to writejs_runtime/node/index_cache.jsonwith a ~3600s TTL from the real nodejs.org response.