Problem
scripts/validation/__tests__/test-wiring.test.js spawns a nested Jest process from inside a Jest test:
function jestListTests(cwd, extraArgs = []) {
const result = spawnSync(
process.execPath,
['node_modules/jest/bin/jest.js', '--config', '.jest.config.cjs', '--listTests', ...extraArgs],
{ cwd, encoding: 'utf8' }
);
expect(result.status).toBe(0);
return new Set(/* parsed stdout */);
}
If that child returns a truncated --listTests output, listed is a short set and the test reports test files as undiscovered:
● jest runner wiring (#3552) › root jest selects every test file except documented standalone suites
- Array []
+ Array [
+ "integration.test.js",
+ "metrics-collection-orchestrator.test.js",
]
That is a false alarm: both files are discovered normally, and the suite is not actually unwired.
Evidence
Observed 2026-09-25 while landing #3487 on a 282-suite branch:
| Context |
Result |
| Full-suite run |
1 failed (test-wiring.test.js) |
| Same test, run alone, immediately after |
1 failed |
| Same test, 6 consecutive isolated runs |
6 passed |
| Full suite, 6 consecutive runs |
6 passed |
develop after #3487, 3 consecutive full-suite runs |
3 passed |
So it reproduces rarely and does not clear on a re-run, which is the worst combination for a required check: it produces a red build that a re-run hides, and it names innocent files.
Confirmed not caused by the #3572 timing fix. The failure was observed both with and without that change; it then passed 12 consecutive full-suite runs with the change in place.
Why it matters now
#3487 is merged, so Jest is a required gate that fails on any new failure. A test that fails for reasons unrelated to the change under test will block arbitrary pull requests — and because the assertion names specific files, it reads as a real wiring break rather than a flake.
Unlike a timing assertion, this one shells out to a second full Jest process while ~280 other suites are already running. Spawn cost and memory pressure are the plausible mechanism, but it has not been confirmed under instrumentation.
Change
Make the nested listing deterministic rather than dependent on a child process completing cleanly under load.
- Reuse the parent's knowledge where possible instead of spawning: Jest exposes the resolved test list to the parent via the reporters API, or the test can be driven by a config-level assertion instead of a subprocess.
- If the subprocess must stay, make the failure honest: assert on the child's exit status and output completeness first, and fail with a diagnostic that says the listing was incomplete rather than naming test files as undiscovered. A truncated listing should never masquerade as a wiring failure.
- Add a size assertion so a short listing is detected as such: the expected set is known, so an unexpectedly small
listed set is itself the signal.
Whichever route, the test must still fail when a test file genuinely stops being discovered — that is the behaviour it was written for in #3552.
Acceptance
Refs #3552, #3572. Found while landing #3487. The timing-boundary flakes from #3572 are fixed; this is a separate mechanism with the same consequence.
Problem
scripts/validation/__tests__/test-wiring.test.jsspawns a nested Jest process from inside a Jest test:If that child returns a truncated
--listTestsoutput,listedis a short set and the test reports test files as undiscovered:That is a false alarm: both files are discovered normally, and the suite is not actually unwired.
Evidence
Observed 2026-09-25 while landing #3487 on a 282-suite branch:
test-wiring.test.js)developafter #3487, 3 consecutive full-suite runsSo it reproduces rarely and does not clear on a re-run, which is the worst combination for a required check: it produces a red build that a re-run hides, and it names innocent files.
Confirmed not caused by the #3572 timing fix. The failure was observed both with and without that change; it then passed 12 consecutive full-suite runs with the change in place.
Why it matters now
#3487 is merged, so Jest is a required gate that fails on any new failure. A test that fails for reasons unrelated to the change under test will block arbitrary pull requests — and because the assertion names specific files, it reads as a real wiring break rather than a flake.
Unlike a timing assertion, this one shells out to a second full Jest process while ~280 other suites are already running. Spawn cost and memory pressure are the plausible mechanism, but it has not been confirmed under instrumentation.
Change
Make the nested listing deterministic rather than dependent on a child process completing cleanly under load.
listedset is itself the signal.Whichever route, the test must still fail when a test file genuinely stops being discovered — that is the behaviour it was written for in #3552.
Acceptance
Refs #3552, #3572. Found while landing #3487. The timing-boundary flakes from #3572 are fixed; this is a separate mechanism with the same consequence.