| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
Credit to @szmarczak #31029 (comment) |
Sorry, something went wrong.
|
I have been just running git clone ... right now :P The speed is about 500KB/s (speedtest results show 2.5MB/s) - that's quite slow. I don't know if this is because of my location or something else... Thanks for taking care of this :) Edit 1: I guess it's just my location, on my VPS I get 10MB/s. |
Sorry, something went wrong.
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
Sorry, something went wrong.
Sorry, something went wrong.
There was a problem hiding this comment.
lgtm
Sorry, something went wrong.
Sorry, something went wrong.
| res, | ||
| stream, | ||
| common.mustCall((err) => { | ||
| server.close(); |
There was a problem hiding this comment.
Does it make sense to also validate the error here?
Sorry, something went wrong.
There was a problem hiding this comment.
I agree. At least that err is truthy.
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
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
Sorry, something went wrong.
There was a problem hiding this comment.
Bisecting points to 67ed526.
Sorry, something went wrong.
There was a problem hiding this comment.
If that _destroy() completed with an error yes, totally.
Sorry, something went wrong.
There was a problem hiding this comment.
Cool. I’ll add it to the proposals list.
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
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
Sorry, something went wrong.
There was a problem hiding this comment.
lgtm
Sorry, something went wrong.
Co-Authored-By: Ruben Bridgewater <ruben@bridgewater.de>
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
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 <luigipinca@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Stephen Belanger <admin@stephenbelanger.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
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 <luigipinca@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Stephen Belanger <admin@stephenbelanger.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
|
This lands without issues on v12.x-staging after #30869 but the new test fails because the 'error' event is emitted twice. |
Sorry, something went wrong.
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 <luigipinca@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Stephen Belanger <admin@stephenbelanger.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
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 <luigipinca@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Stephen Belanger <admin@stephenbelanger.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
| Back | FazBrowse Home | New Git URL |
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