-
Notifications
You must be signed in to change notification settings - Fork 30.9k
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
stream: check type and range of highWaterMark #13065
Conversation
Adds checks for the type of "highWaterMark" and restricts it to non-negative values. Refs: nodejs#12593
lib/_stream_readable.js
Outdated
this.highWaterMark = (hwm || hwm === 0) ? hwm : defaultHwm; | ||
if (hwm == null) { | ||
var defaultHwm = this.objectMode ? 16 : 16 * 1024; | ||
this.highWaterMark = defaultHwm; |
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.
Can't we just move the ternary to here instead?
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.
Sure, I wanted to, but I think I got an opposing comment when I did the same in one of the first commits of #12593. I cannot find it though, so I will go ahead and change it.
Edit: Done.
lib/_stream_writable.js
Outdated
this.highWaterMark = (hwm || hwm === 0) ? hwm : defaultHwm; | ||
if (hwm == null) { | ||
var defaultHwm = this.objectMode ? 16 : 16 * 1024; | ||
this.highWaterMark = defaultHwm; |
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.
Ditto
I am 👎 in shipping this for v8.0.0, as it will require a major bump of |
FWIW this PR is definitely supposed to be semver-major. As for which major version it gets shipped with, I don't particularly have any opinion on it. |
Deciding whether and when to include this patch is entirely up to you, I just thought it was consensus that it should be implemented at some point. |
@tniessen there is consensus that is needed :). I don't think we are ready to bump readable-stream major right now. |
I'm super against bumping readable-stream just on the grounds that nobody is going to upgrade anytime soon, we should at least put in a warning first and see how many people complain |
At this point it wouldn't make it in time for 8.0.0 anyway (which comes out in just over a week). I'm going to be pulling some semver-majors in either later today or tomorrow but I'm going to be very selective about it. |
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.
Overall LGTM just a few nits.
throw new RangeError('"highWaterMark" must not be negative'); | ||
} | ||
|
||
// cast to ints. |
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.
Nit: I think it's better to start a comment with upper case. The same in the other file.
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.
Yeah this is a remainder from the old code.
|
||
// cast to ints. | ||
this.highWaterMark = Math.floor(hwm); | ||
} |
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.
I recommend to move this part into a generic function that can be called by readable and writable stream to prevent code duplication. This also keeps it always in line as the limits stay the same in both cases.
// cast to ints. | ||
this.highWaterMark = Math.floor(this.highWaterMark); | ||
if (hwm < 0) { | ||
throw new RangeError('"highWaterMark" must not be negative'); |
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.
It would be nice if the internal error types would be used for all new errors.
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 is not actually the case for streams. It's a way bigger chunk of work that we need to do, as we would have to support them in readable-stream
as well.
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.
I see, thanks for the update 👍
so my current inclination is that this is not worth a major bump of readable-streams by itself |
@calvinmetcalf do you think this could land in 9.0.0? |
I am 👎 on landing this on 9. |
@mcollina ... is that a -1 to landing this at all or just right now? |
right now. I'm +1 on the change on itself. |
I added the blocked label. I guess as soon as streams get the next major there will be a couple PRs for it. |
I will do the rebase, address the nits etc. once the streams WG (namely @mcollina) decides when to ship this. |
@mcollina are you fine with landing this on v10? In that case it could be continued. |
I think we should, but I would like to keep thinking about it a bit more. Can we leave it as is? |
@mcollina as far as I know we land a couple of stream changes at the moment that might be breaking, so I personally feel like it is the right time to land this as well. |
I'm 👍 with this change in Node 10. Anyone against this? cc @nodejs/streams |
Can you update the errors to use the new error codes? Those are supported in streams now. |
Closing this in favor of #18098. |
Adds checks for the type of "highWaterMark" and restricts it to non-negative values as suggested here by @mscdex.
Refs: #12593
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
stream