René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"test_runner: --test-force-exit with concurrency silently loses test verdicts (parent reports fewer tests than ran, exit 0)","articleBody":"### Version\n\nv26.5.0 (minimal repro below, macOS arm64, Darwin 25.5.0); also observed on v24.18.0 (our CI)\n\n### Platform\n\nmacOS arm64 (Darwin 25.5.0), also observed on v24.18.0 elsewhere\n\n### Subsystem\n\ntest_runner\n\n### What steps will reproduce the bug?\n\nRun 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.\n\n**Generate 40 files × 50 trivially-passing tests (2000 total):**\n\n```js\n// gen.mjs\nimport fs from 'node:fs';\nconst FILES = 40, TESTS = 50;\nfs.rmSync('tests', { recursive: true, force: true });\nfs.mkdirSync('tests');\nfor (let f = 0; f \u003c FILES; f++) {\n  const lines = [\"import { test } from 'node:test';\"];\n  for (let t = 0; t \u003c TESTS; t++) {\n    lines.push(`test('file ${f} test ${t} — some reasonably long test name padding', () => {});`);\n  }\n  fs.writeFileSync(`tests/f${f}.test.mjs`, lines.join('\\n'));\n}\n```\n\n**Counting reporter (counts leaf verdicts the parent actually received):**\n\n```js\n// count-reporter.mjs\nimport fs from 'node:fs';\nexport default async function* countReporter(source) {\n  let pass = 0, fail = 0;\n  for await (const event of source) {\n    if (event.type === 'test:pass' || event.type === 'test:fail') {\n      if (event.data.details?.type === 'test') {\n        if (event.type === 'test:pass') pass++; else fail++;\n      }\n    }\n  }\n  fs.writeSync(2, `\\nREPORTER-COUNT pass=${pass} fail=${fail} total=${pass + fail}\\n`);\n}\n```\n\n**Run:**\n\n```bash\nnode gen.mjs\nnode --test --test-force-exit --test-concurrency=4 \\\n  --test-reporter=tap --test-reporter-destination=stdout \\\n  --test-reporter=./count-reporter.mjs --test-reporter-destination=stderr \\\n  'tests/*.test.mjs'\n```\n\n### How often does it reproduce? Is there a required condition?\n\nEvery 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:\n\n| run | exit code | parent `# tests` summary | custom reporter count | actual tests |\n|-----|-----------|--------------------------|-----------------------|--------------|\n| 1   | 0         | `# tests 1835`           | 1835                  | 2000         |\n| 2   | 0         | `# tests 1794`           | 1794                  | 2000         |\n| 3   | 0         | `# tests 1936`           | 1936                  | 2000         |\n\nBoth 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.\n\nRequired conditions in our testing: `--test-force-exit` + `--test-concurrency` > 1 (default process isolation).\n\n### What is the expected behavior? Why is that the expected behavior?\n\nEither 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.)\n\n### What do you see instead?\n\nFewer tests reported than ran — `# tests 1835` for a 2000-test suite — with exit code 0 and no diagnostic (see table above).\n\n### Additional information\n\nSuspected 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).\n\nRelated, reviewed, and believed distinct:\n- #54327 / #55099 — same class, parent-side reporter destinations only (fixed).\n- #63432 — event *ordering* in process isolation mode; present in v24.18.0 which still exhibits this loss.\n- #62693 / #62704 — `FileTest` frame parser hang on malformed frames (hang, not loss).\n- #49925 — the original `--test-force-exit` feature request.\n\nWe 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.\n","author":{"url":"https://github.com/fski","@type":"Person","name":"fski"},"datePublished":"2026-07-30T04:59:58Z","url":"https://github.com/nodejs/node/issues/64833"}