René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"test_runner: backport #64706 to v22.x — non-ASCII test stdout can silently drop a whole test file","articleBody":"### Request\n\nPlease consider backporting #64706 (fix for #64061) to the `v22.x` release line.\n\n**State as of 2026-09-09**, checked with the GitHub contents API against `lib/internal/test_runner/runner.js`, looking for `) >>> 0) + kSerializedSizeHeader`:\n\n| ref | has the fix |\n| --- | --- |\n| `main` | yes |\n| `v26.x` | yes |\n| `v24.x`, `v24.x-staging` | yes |\n| `v22.x`, `v22.x-staging` | **no** |\n\n#64706 carries no `dont-land-on-v22.x` label, and I could not find an existing backport request or backport PR for v22.x.\n\nThe line is actively released — the most recent v22 release is v22.23.2 (2026-07-29), three days after #64706 landed on `main` (2026-07-26).\n\n### Why this may deserve more weight than the original report suggested\n\n#64061 was reported as an intermittent CI flake. On v22.19.0 I traced the trigger, and it turns out not to be exotic: **it is ordinary non-ASCII text written to stdout by a test.**\n\n`FileTest.#processRawBuffer` advances `bufferHead` past a consumed message and then reads the next four bytes as a length **without re-checking for the `FF 0F` header**:\n\n```js\nbufferHead = TypedArrayPrototypeSubarray(concatenatedBuffer, fullMessageSize);\nthis.#rawBufferSize = TypedArrayPrototypeGetLength(bufferHead);\n...\nwhile (bufferHead?.length >= kSerializedSizeHeader) {\n  const fullMessageSize = (\n    bufferHead[kV8HeaderLength] \u003c\u003c 24 |\n    bufferHead[kV8HeaderLength + 1] \u003c\u003c 16 |\n    bufferHead[kV8HeaderLength + 2] \u003c\u003c 8 |\n    bufferHead[kV8HeaderLength + 3]\n  ) + kSerializedSizeHeader;          // signed 32-bit\n\n  if (this.#rawBufferSize \u003c fullMessageSize) break;\n```\n\nWhen a test's own stdout follows a report message inside the same read, those bytes are interpreted as a length. Every UTF-8 lead/continuation byte is `>= 0x80`, so any non-ASCII output — CJK, emoji, accented Latin — can make `fullMessageSize` negative, which defeats the `break` guard and hands garbage to `DefaultDeserializer`.\n\nIn our repository the emitter was a server start-up banner containing an emoji, printed by the code under test. Three sightings over two days, always the same test file.\n\n### Minimal deterministic reproduction\n\nNo load, no concurrency, no flakiness. One `write()`:\n\n```js\n// repro.mjs   —   node --test repro.mjs\nimport { writeSync } from 'node:fs';\nimport test from 'node:test';\nimport { DefaultSerializer } from 'node:v8';\n\ntest('a passing test', () => {});\n\nconst s = new DefaultSerializer();\ns.writeHeader();\ns.writeValue({ __proto__: null, type: 'test:diagnostic',\n               data: { __proto__: null, nesting: 0, message: 'hi', file: 'repro.mjs' } });\nconst payload = s.releaseBuffer();\nconst size = Buffer.alloc(4);\nsize.writeUInt32BE(payload.length);\nconst message = Buffer.concat([Buffer.from([0xff, 0x0f]), size, payload]);\n\n// a report message, immediately followed by ordinary test stdout, in ONE write\nconst tail = process.env.ASCII ? '\\nserver listening -> http://localhost:3456\\n'\n                               : '\\n\\u{1F7E1} 서버 실행 중 -> http://localhost:3456\\n';\nwriteSync(1, Buffer.concat([message, Buffer.from(tail, 'utf8')]));\n```\n\nOn **v22.19.0, Windows 11 x64**:\n\n```\n$ node --test repro.mjs\nnot ok 1 - repro.mjs\n  error: 'Unable to deserialize cloned data due to invalid or unsupported version.'\n# fail 1\n\n$ ASCII=1 node --test repro.mjs\nok 1 - a passing test\n# fail 0\n```\n\nThe only difference between the two runs is whether the trailing stdout is ASCII.\n\nI only have v22.19.0 on this machine, so I have **not** run this against a fixed release line — the report above is strictly about v22.19.0.\n\n### Three symptoms, and one of them is silent\n\nAlso observed on v22.19.0, depending on where in the stream the corruption lands:\n\n1. a file-level failure carrying the message above (the symptom in #64061);\n2. **the file's results vanish with no failure and no summary.** Running a poisoned file together with a healthy one printed only the healthy file's `ok 1` / `ok 2` — no `1..N`, no `# tests`, no `# fail`, no error text. The exit code was `1`, but the TAP body reads as a clean pass;\n3. with a length byte below `0x80` but large, the runner waits for a message that never arrives and **hangs**.\n\nSymptom 2 is the reason I am filing this: on a line that is still in service, a whole test file can drop out of a run while the output looks green, and only the exit code disagrees.\n\n### Offer\n\nIf the missing step is just a `backport-requested-v22.x` label or an approval, I am happy to open the `[v22.x backport]` PR against `v22.x-staging` — please say so.\n","author":{"url":"https://github.com/positivef","@type":"Person","name":"positivef"},"datePublished":"2026-09-09T11:15:39Z","url":"https://github.com/nodejs/node/issues/65934"}