-
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
[v9.x] stream: always reset awaitDrain when emitting data #18911
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 <apapirovski@mac.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Minwoo Jung <minwoo@nodesource.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
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