Sitelet https://github.com/lightspeedwp/.github/issues/3575
Skip to content

test: test-wiring spawns a nested Jest and reports innocent files as undiscovered under load #3575

Description

@eleshar

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

  • Passes 20 consecutive full-suite runs
  • Still fails when a test file is genuinely excluded from the Jest run — verified by fault injection, not by deleting the assertion
  • A truncated or failed nested listing reports that fact, not a list of files as undiscovered

Refs #3552, #3572. Found while landing #3487. The timing-boundary flakes from #3572 are fixed; this is a separate mechanism with the same consequence.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Fields

Priority

None yet

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions