test_runner: --test-force-exit with concurrency silently loses test verdicts (parent reports fewer tests than ran, exit 0)

Version

v26.5.0 (minimal repro below, macOS arm64, Darwin 25.5.0); also observed on v24.18.0 (our CI)

Platform

macOS arm64 (Darwin 25.5.0), also observed on v24.18.0 elsewhere

Subsystem

test_runner

What steps will reproduce the bug?

Run many fast test files under --test-force-exit with --test-concurrency > 1. The parent process silently loses a fraction of the test verdicts: reporters (both built-in tap and a custom one) receive fewer test:pass/test:fail events than tests that actually ran, the parent's own # tests summary counter drops by the same amount, and the run still exits 0. No warning or error of any kind.

Generate 40 files × 50 trivially-passing tests (2000 total):

// gen.mjs
import fs from 'node:fs';
const FILES = 40, TESTS = 50;
fs.rmSync('tests', { recursive: true, force: true });
fs.mkdirSync('tests');
for (let f = 0; f < FILES; f++) {
  const lines = ["import { test } from 'node:test';"];
  for (let t = 0; t < TESTS; t++) {
    lines.push(`test('file ${f} test ${t} — some reasonably long test name padding', () => {});`);
  }
  fs.writeFileSync(`tests/f${f}.test.mjs`, lines.join('\n'));
}

Counting reporter (counts leaf verdicts the parent actually received):

// count-reporter.mjs
import fs from 'node:fs';
export default async function* countReporter(source) {
  let pass = 0, fail = 0;
  for await (const event of source) {
    if (event.type === 'test:pass' || event.type === 'test:fail') {
      if (event.data.details?.type === 'test') {
        if (event.type === 'test:pass') pass++; else fail++;
      }
    }
  }
  fs.writeSync(2, `\nREPORTER-COUNT pass=${pass} fail=${fail} total=${pass + fail}\n`);
}

Run:

node gen.mjs
node --test --test-force-exit --test-concurrency=4 \
  --test-reporter=tap --test-reporter-destination=stdout \
  --test-reporter=./count-reporter.mjs --test-reporter-destination=stderr \
  'tests/*.test.mjs'

How often does it reproduce? Is there a required condition?

Every run in our testing (21/21 runs lost verdicts), with a different loss each time. Three consecutive runs of the exact command above on v26.5.0:

run	exit code	parent # tests summary	custom reporter count	actual tests
1	0	# tests 1835	1835	2000
2	0	# tests 1794	1794	2000
3	0	# tests 1936	1936	2000

Both reporters always agree with each other and with the summary counters — the events never reach the parent at all. Removing --test-force-exit (same command otherwise) reports exactly 2000/2000 every time. Loss magnitude varies (we've seen 25–234 of 2000, ~1–12%) and occurs at every concurrency level we tried on a larger real suite; higher concurrency loses more.

Required conditions in our testing: --test-force-exit + --test-concurrency > 1 (default process isolation).

What is the expected behavior? Why is that the expected behavior?

Either every verdict from every child is reported before the forced exit, or the runner fails loudly when it knows it dropped report data. Silent partial results defeat the purpose of a test run: on our production suite (Node v24.18.0, 1351 tests) the parent reported as few as 1168 — and since exit code stays 0 when the lost fragments contain only passes, CI stays green while a meaningful fraction of the suite is unaccounted for. A failing test whose verdict lands in a lost fragment is never printed, so the failure detail can vanish from logs even when the child's non-zero exit still fails the run. (To be precise about what we measured: in the minimal repro the injected failure's verdict happened to survive all 15 sample runs and exit stayed 1; the silent loss of pass verdicts with exit 0 reproduces on every all-pass run.)

What do you see instead?

Fewer tests reported than ran — # tests 1835 for a 2000-test suite — with exit code 0 and no diagnostic (see table above).

Additional information

Suspected mechanism: --test-force-exit calls process.exit() while child→parent report streams are still flushing, so V8-serialized test-event frames from process-isolated children are truncated/dropped before the parent's FileTest parser consumes them. This is the same failure class that #54327 reported for reporter destination files and #55099 fixed — but that fix only awaits the reporter destinations' close() on the parent side before exiting. The flush guarantee was never extended one layer up, to the child→parent report stream itself, which is where these events are being lost (a reporter writing synchronously on every event still never sees them).

Related, reviewed, and believed distinct:

• #54327 / #55099 — same class, parent-side reporter destinations only (fixed).
• #63432 — event ordering in process isolation mode; present in v24.18.0 which still exhibits this loss.
• #62693 / #62704 — FileTest frame parser hang on malformed frames (hang, not loss).
• #49925 — the original --test-force-exit feature request.

We currently work around this in CI with a committed manifest of expected tests plus a completeness gate that re-runs files whose verdicts went missing — it works, but it amounts to reimplementing "report everything you ran" outside the runner.

Start by reproducing the exact command with --test-force-exit and --test-concurrency, then trace the test_runner path through FileTest and the child-to-parent report stream. The issue names no source files or tests, so follow those entry points first. Done means all 2,000 leaf verdicts reach both reporters consistently, or dropped data produces a diagnostic and non-success result.