-
Notifications
You must be signed in to change notification settings - Fork 576
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 Regression in v4.x #112
Comments
It might be worth noting that nodejs/node#7278 is distinct (although not unrelated) from nodejs/node#7159, will need its own bugfix and also existed in all Node.js versions prior to 4.2.0. |
As promised, a bit of writeup of the issues/PRs involved in this situation, as a general overview and also for myself to keep track of things (sorry if it’s a bit messy/unreadable/overlong, I’m tired and going to sleep now. 😄):
|
Beautifully illustrates the problems we have with Streams in core, an endless game of wac-a-mole where most people eventually decide that it's too risky to touch anything so stay right away from it. tbh I can't spare enough brain space to get fully around this issue to express much of an opinion on the best way forward: wait, backport, revert — each of these has risks so someone has to make a call on which is the least risky path. I would prefer if @addaleax and @thealphanerd could come up with a shared perspective on an appropriate path forward for LTS and tell the rest of us what to think! |
A couple of notes:
The situation is actually made worse by readable-stream, we should push out a release there soon (we can even test there). We should use that to test this, I'll look for a module that was broken by this. |
The fixes for the bugs listed here have lived in 6.2.2 for almost a week, and I’d feel comfortable seeing them included in one of the next v4 releases. If they don’t, reverting nodejs/node#6023 temporarily should also be okay – the problem it solved is, for the most part, a performance issue, so that should be safe, too. I don’t know how exactly this interacts with the security releases; the decision is yours (@rvagg’s? @thealphanerd’s?) anyway, but both options seem better than “just waiting” to me. |
I've landed the fixes from nodejs/node#7292 and nodejs/node#7160 in The plan right now is to release the security update tomorrow as |
fixed in v4.4.7 |
@mcollina I don’t know, what’s the process for getting the fixes here out in a |
We landed nodejs/node#6023 to fix nodejs/node#5820
This has created a regression that has had two different issues opened
nodejs/node#7159
nodejs/node#7278
There is a potential fix, but it has not yet lived in a release, and may not covered one of the edge cases mentioned in nodejs/node#7278
I think that it might be wise to revert nodejs/node#6023 in the next release.
The text was updated successfully, but these errors were encountered: