-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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: pipeline should use req.abort() to destroy response #31054
Conversation
b4a4544
to
16b4ed4
Compare
Credit to @szmarczak #31029 (comment) |
I have been just running Edit 1: I guess it's just my location, on my VPS I get 10MB/s. |
destroy(err) on http response will propagate the error to the request causing 'error' to be unexpectedly emitted. Furthermore, response.destroy() unlike request.abort() does not _dump buffered data. Fixes a breaking change introduced in nodejs@6480882. Prefer res.req.abort() over res.destroy() until this situation is clarified. Fixes: nodejs#31029 Refs: nodejs@6480882
16b4ed4
to
6dd8500
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.
lgtm
res, | ||
stream, | ||
common.mustCall((err) => { | ||
server.close(); |
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.
Does it make sense to also validate the error here?
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 agree. At least that err
is truthy.
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.
Fixed. Unfortunately we get an unexpected/different error (ERR_STREAM_DESTROYED
) due to the behavior discussed in #31060. So I made it just check for truthyness.
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 can't understand how this is related to #31060. AFAIK none of the _destroy()
implementations is async.
It seems a regression on master to me
const stream = require('stream');
const data = Buffer.alloc(1024);
{
const readable = new stream.Readable({
read() {
this.push(data);
}
});
const writable = new stream.Writable({
write(chunk, encoding, callback) {
callback();
}
});
writable.on('error', console.error);
readable.pipe(writable);
writable.destroy(new Error('Oops'));
}
{
const readable = new stream.Readable({
read() {
this.push(data);
}
});
const writable = new stream.Writable({
write(chunk, encoding, callback) {
callback();
}
});
stream.pipeline(readable, writable, console.error);
writable.destroy(new Error('Oops'));
}
This prints
Error: Oops
at Object.<anonymous> (/Users/luigi/Desktop/pipe.js:23:20)
at Module._compile (internal/modules/cjs/loader.js:1139:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1159:10)
at Module.load (internal/modules/cjs/loader.js:988:32)
at Function.Module._load (internal/modules/cjs/loader.js:896:14)
at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:71:12)
at internal/main/run_main_module.js:17:47
Error: Oops
at Object.<anonymous> (/Users/luigi/Desktop/pipe.js:41:20)
at Module._compile (internal/modules/cjs/loader.js:1139:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1159:10)
at Module.load (internal/modules/cjs/loader.js:988:32)
at Function.Module._load (internal/modules/cjs/loader.js:896:14)
at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:71:12)
at internal/main/run_main_module.js:17:47
on Node.js 13.5.0 and
Error [ERR_STREAM_DESTROYED]: Cannot call write after a stream was destroyed
at Writable.write (_stream_writable.js:321:17)
at Readable.ondata (_stream_readable.js:779:22)
at Readable.emit (events.js:320:20)
at Readable.read (_stream_readable.js:579:10)
at flow (_stream_readable.js:1052:34)
at resume_ (_stream_readable.js:1033:3)
at processTicksAndRejections (internal/process/task_queues.js:84:21) {
code: 'ERR_STREAM_DESTROYED'
}
Error [ERR_STREAM_DESTROYED]: Cannot call write after a stream was destroyed
at Writable.write (_stream_writable.js:321:17)
at Readable.ondata (_stream_readable.js:779:22)
at Readable.emit (events.js:320:20)
at Readable.read (_stream_readable.js:579:10)
at flow (_stream_readable.js:1052:34)
at resume_ (_stream_readable.js:1033:3)
at processTicksAndRejections (internal/process/task_queues.js:84:21) {
code: 'ERR_STREAM_DESTROYED'
}
on Node.js master
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.
Bisecting points to 67ed526.
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.
If that _destroy()
completed with an error yes, totally.
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.
Cool. I’ll add it to the proposals list.
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.
How can this thread be resolved? We need a fix with the bug this PR aims to solve for node v13, or better revert the few commits that caused the problem in the first place.
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 don't think this specific thread needs to be urgently resolved (or at the least it's a different issue). This PR in its current form resolves the original issue.
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.
Agreed, this discussion should not block the PR. The issue discussed here is caused by a semver-major change that will not be included in v13.x
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.
lgtm
Co-Authored-By: Ruben Bridgewater <[email protected]>
Landed in c852f7e |
destroy(err) on http response will propagate the error to the request causing 'error' to be unexpectedly emitted. Furthermore, response.destroy() unlike request.abort() does not _dump buffered data. Fixes a breaking change introduced in 6480882. Prefer res.req.abort() over res.destroy() until this situation is clarified. Fixes: #31029 Refs: 6480882 PR-URL: #31054 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Stephen Belanger <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]>
destroy(err) on http response will propagate the error to the request causing 'error' to be unexpectedly emitted. Furthermore, response.destroy() unlike request.abort() does not _dump buffered data. Fixes a breaking change introduced in 6480882. Prefer res.req.abort() over res.destroy() until this situation is clarified. Fixes: #31029 Refs: 6480882 PR-URL: #31054 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Stephen Belanger <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]>
This lands without issues on v12.x-staging after #30869 but the new test fails because the |
destroy(err) on http response will propagate the error to the request causing 'error' to be unexpectedly emitted. Furthermore, response.destroy() unlike request.abort() does not _dump buffered data. Fixes a breaking change introduced in nodejs@6480882. Prefer res.req.abort() over res.destroy() until this situation is clarified. Fixes: nodejs#31029 Refs: nodejs@6480882 PR-URL: nodejs#31054 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Stephen Belanger <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]>
destroy(err) on http response will propagate the error to the request causing 'error' to be unexpectedly emitted. Furthermore, response.destroy() unlike request.abort() does not _dump buffered data. Fixes a breaking change introduced in 6480882. Prefer res.req.abort() over res.destroy() until this situation is clarified. Fixes: #31029 Refs: 6480882 PR-URL: #31054 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Stephen Belanger <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]>
destroy(err) on http response will propagate the error to the
request causing 'error' to be unexpectedly emitted. Furthermore,
response.destroy() unlike request.abort() does not _dump buffered
data.
Fixes a breaking change applied in 6480882.
Prefer res.req.abort() over res.destroy() until this situation is
clarified.
This is a bugfix and I believe it should be semver minor.
Fixes #31029.
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes