-
Notifications
You must be signed in to change notification settings - Fork 16.2k
fix: allow ClientRequest responses to be throttled #25531
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
e55c02c
to
4010f83
Compare
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.
looks good to me!
I'd rewrite the release notes a little to not mention internal C++ class names. Maybe something like "Fixed an issue where net.request would continue downloading data even when the consuming stream was throttled"? |
@nornagon Definitely! Will make that change now |
4010f83
to
bbc322f
Compare
Interesting! It looks like this test is failing on Linux, even though it's succeeding on Mac. I wonder if the kernel buffers are bigger on our CI machine? I just checked on my Ubuntu VM and I found:
these three numbers are min/default/max size of the kernel's read and write buffers, respectively. The max size there is 6MB in the read buffer and 4MB in the write buffer, for a total of 10MB, which is roughly equal to the 9 chunks that the server successfully manages to send. I think it would make sense to solve this by changing the expectation in the test to be <= 10 chunks, and increase the timeout to 1 second (just to be sure that if it was going to send, like, 100 chunks, then we'd definitely get >10). It's not a perfect test—I wish I could think of a way to test this without a |
bbc322f
to
43bf980
Compare
@VerteDinde looks like this is failing:
|
Release Notes Persisted
|
Description of Change
Closes #25130.
Previously, when making a client request, the IncomingMessage class was implementing the Readable stream property correctly. However, its buffer will get filled without stopping by the SimpleURLLoaderWrapper.
This PR passes up a callback from the SimpleURLLoaderWrapper layer to the IncomingMessage class. This callback allows the IncomingMessage class to properly stop the readable stream when it is full and needs the request to pause, and then resume the stream when appropriate.
Checklist
npm test
passesRelease Notes
Notes: Fixed an issue where net.request would continue downloading data even when the consuming stream was throttled.