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 648088289d.
Prefer res.req.abort() over res.destroy() until this situation is
clarified.
Fixes: https://github.com/nodejs/node/issues/31029
Refs: 648088289d
PR-URL: https://github.com/nodejs/node/pull/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 updates a lot of comments.
PR-URL: https://github.com/nodejs/node/pull/26223
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
Splitting out the http2 portion of the test has a few benfits:
* We don't skip the rest of the tests if `node` is compiled without
crypto.
* We can find out if the http2 portion of the test is responsible for
the timeouts reported in issue 24456.
Refs: https://github.com/nodejs/node/issues/24456
PR-URL: https://github.com/nodejs/node/pull/24631
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
This test is ported automatically in readable-stream, and it fails there
on Windows and older Node.js versions because of some bad interactions
between the code and the event loop on Windows.
See: https://github.com/nodejs/readable-stream/issues/353
PR-URL: https://github.com/nodejs/node/pull/22456
Reviewed-By: Mathias Buus <mathiasbuus@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
This commit removes `common.crashOnUnhandledRejection()` and adds
`common.disableCrashOnUnhandledRejection()`.
To reduce the risk of mistakes and make writing tests that involve
promises simpler, always install the unhandledRejection hook in tests
and provide a way to disable it for the rare cases where it's needed.
PR-URL: https://github.com/nodejs/node/pull/21849
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Right now when not adding a callback to the pipeline it could cause
an uncaught exception if there is an error. Instead, just make the
callback mandatory as mostly done in all other Node.js callback APIs
so users explicitly have to decide what to do in such situations.
PR-URL: https://github.com/nodejs/node/pull/21054
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
The bug referenced in this TODO was fixed and this test no longer
requires this code to pass.
PR-URL: https://github.com/nodejs/node/pull/21145
Reviewed-By: Rich Trott <rtrott@gmail.com>
Fixes an issue where Stream.pipeline wouldn't re-throw errors
on a stream if no callback was specified, thus swallowing
said errors.
Fixes: https://github.com/nodejs/node/issues/20303
PR-URL: https://github.com/nodejs/node/pull/20437
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
