PTY snapshot suite: rare non-repeating case failures under parallel load (pass in isolation)
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
Research direction
Start with just snapshot-test migration and the PTY snapshot runner, using rust-toolchain.toml and the listed migration fixtures as the reproduction surface. Compare cold-cache parallel runs with isolated and warm runs, adding the suggested timing, verbosity, or retry instrumentation. Done means the load-sensitive failures are explained and the migration suite no longer produces unexplained intermittent failures.
Written by the indexing model from the issue text.
Description
Summary
Running the full migration* PTY snapshot suite in parallel occasionally fails a small, non-repeating set of cases (~0.4% of case-executions). Every affected case passes deterministically when run in isolation, and the failing names differ between runs — so this looks like load-sensitivity in the PTY runner environment rather than any individual fixture or product bug. Filing per m0g3r's suggestion in #2483 after it showed up there first.
Observations (macOS arm64, M-series, just snapshot-test migration)
Five full-suite runs across two commits, all with a fresh packages/cli/dist (freshness guard green):
| run | commit | result | failed cases |
|---|---|---|---|
| A | 31163c5 (PR #2483 branch) |
151/154 | migration_dynamic_oxc_configs, migration_framework_shim_vue, migration_standalone_yarn4_idempotent |
| B | cc20535d (main) |
159/161 | migration_not_supported_vitest3, migration_from_tsup_monorepo_success |
| C | cc20535d (main) |
161/161 | — |
| D | cc20535d (main) |
161/161 | — |
| E | 31163c5, earlier same-day |
148/154 | different set again (incl. migration_husky_or_prepare, migration_standalone_bun_install) |
- No case name repeats across runs. Union of failures over five runs: 10+ distinct fixtures, each failing exactly once.
- Every one of them passes in isolation (
just snapshot-test <name>), immediately after the failing run, unchanged tree. - The failure-heavy runs were the first suite run after a fresh build / cold caches; warm re-runs (C, D) were fully green. Cold-state work on first touch (managed runtime provisioning, registry-bridge first hits) overlapping with ~14 parallel PTY cases is my best guess at the mechanism, but I have not isolated it.
- m0g3r additionally verified in #2483 that the flaked fixtures are structurally unremarkable (step counts mid-pack; one of 21 double-
vp migratefixtures).
Why it may matter
Locally it's a shrug; in CI a 0.4% per-case flake across ~650 cases makes a meaningful fraction of runs red for reasons unrelated to the diff under test, and the changing names make it hard for contributors to tell signal from noise (it cost a round of triage on #2483).
Environment
- macOS arm64 (Darwin 25.2), 14 threads reported by the runner
just snapshot-test migration(both flavors), toolchain perrust-toolchain.toml
Happy to re-run with any added instrumentation (timings, per-case retries, runner verbosity) if that helps narrow it — I can reproduce roughly one flaky run per two or three cold full-suite runs.
- Dominant language
- Rust
- Stars
- 5.8k
- Forks
- 267
- Avg merge
- 20h 7m
- Merged PRs (30d)
- 139
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from voidzero-dev/vite-plus
-
pending triage
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
voidzero-dev/vite-plus#2854 · 1 assignee ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
voidzero-dev/vite-plus#2849 ·
Maintainers usually reply within 1 day
-
pending triage
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
voidzero-dev/vite-plus#2801 · 1 reaction ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
voidzero-dev/vite-plus#2097 · 10 comments · 2 reactions ·
Maintainers usually reply within 1 day
-
pending triage
Difficulty 4/5 3-5 days Newbie friendliness 48/100
voidzero-dev/vite-plus#2866 · 1 assignee ·
Maintainers usually reply within 1 day
All issues in voidzero-dev/vite-plus
Similar issues
-
discover: `sudo RTK_DISABLED=$VAR …` is not detected as a bypass when `sudo` is a transparent prefixOpenarea:cli bug good first issue priority:medium
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
skill:code-review
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
component:sight
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
agentic-os-org/ANOLISA#4115 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
rivet-dev/rivet#5819 · 1 comment ·
Maintainers usually reply within 1 day
-
A-io-database bug needs triage python
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 1 day