-
-
Notifications
You must be signed in to change notification settings - Fork 34k
[v9.x] stream: always reset awaitDrain when emitting data #18911
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
Conversation
b9b5810 to
6edf952
Compare
6240178 to
5de36de
Compare
|
New CI: https://ci.nodejs.org/job/node-test-pull-request/13376/ Could I get an approval on this? |
2177138 to
319cd44
Compare
19c46aa to
1246902
Compare
|
@addaleax looks like this could use a rebase and another CI run |
75211b6 to
e4c10f7
Compare
|
@nodejs/streams I’m not sure why this test is failing, but it seems like it’s more complex and has to do with different timing between The failure looks like this: |
The complicated `awaitDrain` machinery can be made a bit
slimmer, and more correct, by just resetting the value
each time `stream.emit('data')` is called.
By resetting the value before emitting the data chunk, and
seeing whether any pipe destinations return `.write() === false`,
we always end up in a consistent state and don’t need to worry
about odd situations (like `dest.write(chunk)` emitting more data).
PR-URL: nodejs#18516
Fixes: nodejs#18484
Fixes: nodejs#18512
Refs: nodejs#18515
Reviewed-By: Anatoli Papirovski <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Minwoo Jung <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
e4c10f7 to
b26d272
Compare
|
|
|
@mcollina next steps for this PR? |
|
I’m not sure how to fix the issues I was getting here – and it does seem like this is still a valid and necessary bug fix, the test fails without the changes to the streams code on v9.x. |
759b210 to
4e9ac10
Compare
|
I will need to have a look. The fix for v9.x (and 8.x) might be more complicated. This is probably leveraging #18515 (which is semver-major). |
630a653 to
ef4714c
Compare
|
I do not think this is backportable to 9 or 8. I think we can close this and flag #18516 as dont-land-on-9. It might be possible to do a completely different fix for the issue on 8 or 9, but I don't see this severe enough to be worth the effort (but happy to reconsider if there is a specific need). |
|
Ok, I’ll close this then. Thanks for investigating! And I agree, if somebody runs into this issue we can still look into it in more details. |
Backport of #18516, only conflict being the added
debug()line that is being borrowed from 1e0f331