stream: fix Writable.toWeb() hang on synchronous drain#61197
Merged
nodejs-github-bot merged 1 commit intoMay 22, 2026
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #61197 +/- ##
==========================================
- Coverage 90.06% 90.04% -0.02%
==========================================
Files 714 714
Lines 225918 225921 +3
Branches 42735 42744 +9
==========================================
- Hits 203471 203434 -37
- Misses 14232 14276 +44
+ Partials 8215 8211 -4
🚀 New features to boost your workflow:
|
Contributor
Failed to start CI⚠ No approving reviews found ✘ Refusing to run CI on potentially unsafe PRhttps://github.com/nodejs/node/actions/runs/20606939876 |
1e7c128 to
ec84fd4
Compare
ec84fd4 to
6fc9709
Compare
6fc9709 to
d1c83ac
Compare
Member
|
@Han5991 I rebased you branch from main, but you need to sign your commit as per guidelines. Can you check out the latest branch, and run:
|
A race condition in the Writable.toWeb() adapter caused the stream to hang if the underlying Node.js Writable emitted a 'drain' event synchronously during a write() call. This often happened when highWaterMark was set to 0. By checking writableNeedDrain immediately after a backpressured write, the adapter now correctly detects if the stream has already drained, resolving the backpressure promise instead of waiting indefinitely for an event that has already occurred. Fixes: nodejs#61145 Signed-off-by: sangwook <rewq5991@gmail.com>
d1c83ac to
db7eab3
Compare
Contributor
Author
Thanks for letting me know! |
trivikr
approved these changes
May 21, 2026
Collaborator
This comment was marked as outdated.
This comment was marked as outdated.
jasnell
approved these changes
May 22, 2026
Collaborator
|
Landed in 7e7bde8 |
aduh95
pushed a commit
that referenced
this pull request
May 22, 2026
A race condition in the Writable.toWeb() adapter caused the stream to hang if the underlying Node.js Writable emitted a 'drain' event synchronously during a write() call. This often happened when highWaterMark was set to 0. By checking writableNeedDrain immediately after a backpressured write, the adapter now correctly detects if the stream has already drained, resolving the backpressure promise instead of waiting indefinitely for an event that has already occurred. Fixes: #61145 Signed-off-by: sangwook <rewq5991@gmail.com> PR-URL: #61197 Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
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.
This PR fixes a race condition in Writable.toWeb() where the resulting WritableStream would hang if the underlying Node.js
Writable emitted the 'drain' event synchronously during a write() call.
This issue typically manifests when highWaterMark is set to 0, or in custom stream implementations that do not defer 'drain'
emissions. In such cases, the 'drain' event could fire before the adapter had a chance to set up the backpressurePromise and the
listener, causing the adapter to wait indefinitely for an event that had already occurred.
The fix involves checking streamWritable.writableNeedDrain immediately after write() returns false. If the stream is already
drained (i.e., writableNeedDrain is false), the backpressure promise is resolved immediately.
Related Issue
Fixes: #61145