Prevent hang when output is requested after Stream input has finished - #4584
Open
Jaybhade wants to merge 1 commit into
Open
Prevent hang when output is requested after Stream input has finished#4584Jaybhade wants to merge 1 commit into
Jaybhade wants to merge 1 commit into
Conversation
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Every Stream-based input path waits for the Writable side to emit
finishbefore flattening the accumulated chunks.finishis 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.Measured against
main, waiting 2s for each call on an instance whose Writable side has already finished:toBuffer()toBuffer(callback)toFile(path)metadata()metadata(callback)stats()stats(callback)clone()then output.pipe(writable)The two that already worked each carry their own workaround for this, added one entry point at a time:
metadata()checkswritableFinished(df97120, #3451) and Stream output re-emitsfinishwhenstreamInFinishedis set (d8df503, #671). Everything else was left waiting on an event that had gone.Fix
Both ad-hoc guards are replaced with a single
_whenStreamInFinishedhelper, used everywhere the input stream is awaited: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 readingstreamInFinished, its bookkeeping in_writegoes too — and with it thefinishlistener 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
writableFinisheddoes 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 afterfinishhas been awaited. Seven of them hang onmainand 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 testis otherwise unchanged: 1821 tests, 100% branch coverage retained.