`stream.pipeline()` can both throw synchronously and invoke the callback reporting success
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 55/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Tranquilla
- Stack tecnologico
- javascript
- Ambito
- backend
Direzione di ricerca
Inizia nel loop di wiring di stream pipelineImpl(), concentrandoti su finishCount e sul percorso di throw sincrono descritto nel report. Riproduci i casi A e B dell’issue, quindi verifica che un throw sincrono non invochi successivamente il callback con successo e che il callback non venga invocato due volte.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Version
v24.11.1, and main (aed4eaf89dd)
Platform
Reproduced on Windows 11 x64; the code path is platform independent.
Subsystem
stream
What steps will reproduce the bug?
When 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.
import { pipeline, Readable, Transform, PassThrough } from 'node:stream';
function run(label, streams) {
return new Promise((resolve) => {
let threw = null;
const calls = [];
try {
pipeline(...streams, (err) => calls.push(err ? err.code : 'NO ERROR'));
} catch (err) {
threw = err.code;
}
setTimeout(() => {
console.log(`${label}`);
console.log(` threw : ${threw}`);
console.log(` callback invoked : ${calls.length} time(s) ${calls.length ? JSON.stringify(calls) : ''}`);
resolve();
}, 150);
});
}
// A node stream in the middle wires pipe(), which increments finishCount
// before the later stage throws.
await run('A. readable -> transform -> bad fn', [
Readable.from(['a']),
new Transform({ transform(c, e, cb) { cb(null, c); } }),
() => 42,
]);
// Control: the throw happens before anything increments finishCount.
await run('B. readable -> bad fn -> passthrough (control)', [
Readable.from(['a']),
() => 42,
new PassThrough(),
]);
How often does it reproduce? Is there a required condition?
Every 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.
What is the expected behavior? Why is that the expected behavior?
A 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.
Case B shows the intended behaviour: the callback is not invoked when pipeline() throws.
What do you see instead?
node v24.11.1
A. readable -> transform -> bad fn
threw : ERR_INVALID_RETURN_VALUE
callback invoked : 1 time(s) ["NO ERROR"]
B. readable -> bad fn -> passthrough (control)
threw : ERR_INVALID_RETURN_VALUE
callback invoked : 0 time(s)
In case A the caller gets an ERR_INVALID_RETURN_VALUE exception and, shortly afterwards, a callback saying the pipeline finished with no error.
Additional information
The 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).
Because the streams were never destroyed by pipeline() on this path, error is still undefined at that point, so the callback reports success.
In 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.
This was noticed while working on #65064, which touches the same synchronous-throw path but deliberately does not change this behaviour.
- Lingua principale
- JavaScript
- Stelle
- 122k
- Fork
- 37.4k
- Merge medio
- 4g 4h
- PR unite (30g)
- 276
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di nodejs/node
-
doc
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
-
build
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
-
feature request
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
Issue simili
-
bug customer-eng Durable Agents Inngest status: needs triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
-
optimization optimization:agents-md-curator
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
githubnext/gh-aw-cao#13475 ·
-
[BUG]: "Clear All" in Settings doesn't clear the saved analysis, old data comes back after reload Apertabug
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
AOSSIE-Org/OrgExplorer#253 · 1 commento ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
oxc-project/oxc#26944 ·
-
ai-observability bug team/ai-observability
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100