-
Notifications
You must be signed in to change notification settings - Fork 29.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
streams: fix cloned webstreams not being unref'd #51255
streams: fix cloned webstreams not being unref'd #51255
Conversation
When cloning a `ReadableStream` and `WritableStream`, both use an internal `MessageChannel` to communicate with the original stream. Those, however, previously were not unref'd which would lead to the process not exiting if the stream was not fully consumed. Fixes: nodejs#44985
Thank you! |
299f752
to
2ac4765
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this will hopefully fix a few issues in fetch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, but I would really consider this a bugfix rather than a semver-major change.
How about we tag it as "baking for lts" instead and wait if we actually break folks?
Commit Queue failed- Loading data for nodejs/node/pull/51255 ✔ Done loading data for nodejs/node/pull/51255 ----------------------------------- PR info ------------------------------------ Title streams: fix cloned webstreams not being unref'd (#51255) Author James M Snell (@jasnell) Branch jasnell:fixup-webstreams-clone-hang -> nodejs:main Labels baking-for-lts, author ready, web streams Commits 2 - stream: fix cloned webstreams not being unref'd - Update test/parallel/test-whatwg-webstreams-transfer.js Committers 2 - James M Snell - GitHub PR-URL: https://github.com/nodejs/node/pull/51255 Fixes: https://github.com/nodejs/node/issues/44985 Reviewed-By: Matthew Aitken Reviewed-By: Matteo Collina ------------------------------ Generated metadata ------------------------------ PR-URL: https://github.com/nodejs/node/pull/51255 Fixes: https://github.com/nodejs/node/issues/44985 Reviewed-By: Matthew Aitken Reviewed-By: Matteo Collina -------------------------------------------------------------------------------- ℹ This PR was created on Fri, 22 Dec 2023 04:21:41 GMT ✔ Approvals: 2 ✔ - Matthew Aitken (@KhafraDev): https://github.com/nodejs/node/pull/51255#pullrequestreview-1794662152 ✔ - Matteo Collina (@mcollina) (TSC): https://github.com/nodejs/node/pull/51255#pullrequestreview-1795456690 ✔ Last GitHub CI successful ℹ Last Full PR CI on 2023-12-22T08:53:12Z: https://ci.nodejs.org/job/node-test-pull-request/56461/ ⚠ Commits were pushed after the last Full PR CI run: ⚠ - Update test/parallel/test-whatwg-webstreams-transfer.js - Querying data for job/node-test-pull-request/56461/ ✔ Last Jenkins CI successful -------------------------------------------------------------------------------- ✔ Aborted `git node land` session in /home/runner/work/node/node/.ncuhttps://github.com/nodejs/node/actions/runs/7312493372 |
Landed in 4d3923a |
When cloning a `ReadableStream` and `WritableStream`, both use an internal `MessageChannel` to communicate with the original stream. Those, however, previously were not unref'd which would lead to the process not exiting if the stream was not fully consumed. Fixes: #44985 PR-URL: #51255 Reviewed-By: Matthew Aitken <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Debadree Chatterjee <[email protected]>
This is being reverted by #51491 so adding dont-land labels. |
When cloning a
ReadableStream
andWritableStream
, both use an internalMessageChannel
to communicate with the original stream. Those, however, previously were not unref'd which would lead to the process not exiting if the stream was not fully consumed.Alternative for: #51131
Fixes: #44985
Semver-major because this can change whether a worker thread stays alive solely because of the existence of the cloned streams vs. needing something else to keep it alive (see the modified test in this PR for instance).