René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"`stream.pipeline()` can both throw synchronously and invoke the callback reporting success","articleBody":"### Version\n\nv24.11.1, and `main` (`aed4eaf89dd`)\n\n### Platform\n\nReproduced on Windows 11 x64; the code path is platform independent.\n\n### Subsystem\n\nstream\n\n### What steps will reproduce the bug?\n\nWhen `pipeline()` throws synchronously while wiring the streams together, it can *also* invoke the callback, and the callback reports success. The caller therefore receives the same operation reported twice, once as an exception and once as a successful completion.\n\n```js\nimport { pipeline, Readable, Transform, PassThrough } from 'node:stream';\n\nfunction run(label, streams) {\n  return new Promise((resolve) => {\n    let threw = null;\n    const calls = [];\n    try {\n      pipeline(...streams, (err) => calls.push(err ? err.code : 'NO ERROR'));\n    } catch (err) {\n      threw = err.code;\n    }\n    setTimeout(() => {\n      console.log(`${label}`);\n      console.log(`   threw            : ${threw}`);\n      console.log(`   callback invoked : ${calls.length} time(s) ${calls.length ? JSON.stringify(calls) : ''}`);\n      resolve();\n    }, 150);\n  });\n}\n\n// A node stream in the middle wires pipe(), which increments finishCount\n// before the later stage throws.\nawait run('A. readable -> transform -> bad fn', [\n  Readable.from(['a']),\n  new Transform({ transform(c, e, cb) { cb(null, c); } }),\n  () => 42,\n]);\n\n// Control: the throw happens before anything increments finishCount.\nawait run('B. readable -> bad fn -> passthrough  (control)', [\n  Readable.from(['a']),\n  () => 42,\n  new PassThrough(),\n]);\n```\n\n### How often does it reproduce? Is there a required condition?\n\nEvery time, for case A. The condition is that `finishCount` has already been incremented by an earlier stage before a later stage throws, which happens whenever a node stream is wired before the throwing stage.\n\n### What is the expected behavior? Why is that the expected behavior?\n\nA single failure should be reported once. If `pipeline()` throws synchronously then the callback should not also run, and it certainly should not run with no error, since the pipeline did not succeed.\n\nCase B shows the intended behaviour: the callback is not invoked when `pipeline()` throws.\n\n### What do you see instead?\n\n```\nnode v24.11.1\n\nA. readable -> transform -> bad fn\n   threw            : ERR_INVALID_RETURN_VALUE\n   callback invoked : 1 time(s) [\"NO ERROR\"]\n\nB. readable -> bad fn -> passthrough  (control)\n   threw            : ERR_INVALID_RETURN_VALUE\n   callback invoked : 0 time(s)\n```\n\nIn case A the caller gets an `ERR_INVALID_RETURN_VALUE` exception and, shortly afterwards, a callback saying the pipeline finished with no error.\n\n### Additional information\n\nThe wiring loop in `pipelineImpl()` increments `finishCount` as it wires each stage, for example `finishCount += 2` before `pipe()` in the node stream branch. If a later stage throws, those already-wired stages remain live. When they subsequently close they call `finish()`, which decrements `finishCount`; on reaching zero `finishImpl()` runs with `final` true and schedules `process.nextTick(callback, error, value)`.\n\nBecause the streams were never destroyed by `pipeline()` on this path, `error` is still undefined at that point, so the callback reports success.\n\nIn case B the throw happens before any stage incremented `finishCount`, so nothing later reaches zero and the callback is correctly never scheduled. That difference is what makes the behaviour inconsistent rather than simply undesirable.\n\nThis was noticed while working on #65064, which touches the same synchronous-throw path but deliberately does not change this behaviour.\n","author":{"url":"https://github.com/shani-singh1","@type":"Person","name":"shani-singh1"},"datePublished":"2026-08-08T05:09:12Z","url":"https://github.com/nodejs/node/issues/65127"}