Skip to content

Prevent hang when output is requested after Stream input has finished - #4584

Open
Jaybhade wants to merge 1 commit into
lovell:mainfrom
Jaybhade:fix/stream-input-already-finished
Open

Prevent hang when output is requested after Stream input has finished#4584
Jaybhade wants to merge 1 commit into
lovell:mainfrom
Jaybhade:fix/stream-input-already-finished

Conversation

@Jaybhade

@Jaybhade Jaybhade commented Aug 6, 2026

Copy link
Copy Markdown

Every Stream-based input path waits for the Writable side to emit finish before flattening the accumulated chunks. finish is emitted only once, so any listener registered after it has already fired never runs — the Promise never settles and the callback is never called, with no error and no timeout.

const pipeline = sharp().resize(320, 240);
createReadStream(input).pipe(pipeline);
await once(pipeline, 'finish');   // or await pipelineAsync(readable, pipeline)

await pipeline.toBuffer();        // hangs forever

Measured against main, waiting 2s for each call on an instance whose Writable side has already finished:

call before after
toBuffer() hangs resolves
toBuffer(callback) hangs resolves
toFile(path) hangs resolves
metadata() resolves resolves
metadata(callback) hangs resolves
stats() hangs resolves
stats(callback) hangs resolves
clone() then output hangs resolves
.pipe(writable) resolves resolves

The two that already worked each carry their own workaround for this, added one entry point at a time: metadata() checks writableFinished (df97120, #3451) and Stream output re-emits finish when streamInFinished is set (d8df503, #671). Everything else was left waiting on an event that had gone.

Fix

Both ad-hoc guards are replaced with a single _whenStreamInFinished helper, used everywhere the input stream is awaited:

function _whenStreamInFinished (fn) {
  if (this.writableFinished) {
    fn();
  } else {
    this.once('finish', fn);
  }
}

Calling the handler directly means Stream output no longer has to re-emit finish, which also stops that event being delivered twice to any listener the caller has attached. With nothing left reading streamInFinished, its bookkeeping in _write goes too — and with it the finish listener that was attached to every Stream-fed instance.

An input stream that finishes without producing any data now rejects with the usual unsupported-format error rather than hanging, since writableFinished does not depend on a chunk having arrived.

No public API or type definitions change.

Tests

Eight cases in test/unit/io.js, one per entry point above, each requesting output only after finish has been awaited. Seven of them hang on main and are only reported as failures by the 60s suite timeout; the eighth (metadata() via Promise) passes both before and after, and is included so the path that had the original workaround stays covered.

npm test is otherwise unchanged: 1821 tests, 100% branch coverage retained.

Every Stream-based input path waits for the Writable side to emit
'finish' before flattening the accumulated chunks. 'finish' is emitted
only once, so any of these registered after it has already fired never
runs: the Promise never settles and the callback is never called, with
no error and no timeout.

    const pipeline = sharp().resize(320, 240);
    createReadStream(input).pipe(pipeline);
    await once(pipeline, 'finish');
    await pipeline.toBuffer(); // never resolves

This affected toBuffer, toFile, metadata via callback, stats and clone.
Two paths already worked around it in isolation: metadata via Promise
checked writableFinished, and Stream output re-emitted 'finish' when
streamInFinished was set.

Replace both ad-hoc guards with a shared _whenStreamInFinished helper
and use it everywhere the input stream is awaited. Re-emitting 'finish'
is no longer needed, so the streamInFinished bookkeeping in _write goes
too, along with the 'finish' listener it attached to every instance.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant