-
Notifications
You must be signed in to change notification settings - Fork 29.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
http2: refactor error handling #14991
Conversation
cc @nodejs/http2 @akc42 |
lib/internal/http2/compat.js
Outdated
@@ -58,8 +58,12 @@ function onStreamEnd() { | |||
} | |||
|
|||
function onStreamError(error) { | |||
const request = this[kRequest]; | |||
request.emit('error', error); | |||
// this is purpusefully left blank |
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.
s/purpusefully/purposefully
lib/internal/http2/core.js
Outdated
const server = session[kServer]; | ||
|
||
if (err && server) { | ||
server.emit('clientError', err, this); |
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.
question: should this be nextTick'd?
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 think so - or at least I'd expect it to. Do we have a guarantee that it will always be deferred by the time _destroy is called?
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.
there is a nextTick
on top, https://github.com/nodejs/node/blob/master/lib/internal/http2/core.js#L1509
_destroy
is called synchronously. But the error of the _destroy
callback will be emitted asynchronously, see https://github.com/nodejs/node/blob/master/lib/internal/streams/destroy.js#L32-L37.
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 but it may be good to add some detail to the documentation.
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 with 2 nits - would love docs for the newly exposed Http2Stream
and Http2Session
lib/http2.js
Outdated
@@ -28,4 +30,6 @@ module.exports = { | |||
connect, | |||
Http2ServerResponse, | |||
Http2ServerRequest, | |||
Http2Session, |
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'm fine with this - but increasing the surface of the API is not trivial - and I'd like to see docs.
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've added them just for test purpose. I'll require the internals.
lib/internal/http2/core.js
Outdated
const server = session[kServer]; | ||
|
||
if (err && server) { | ||
server.emit('clientError', err, this); |
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 think so - or at least I'd expect it to. Do we have a guarantee that it will always be deferred by the time _destroy is called?
The two use cases I have been battling with is
|
22498dd
to
4d49f2a
Compare
I have moved |
I've added a commit that introduces @jasnell @benjamingr please reaffirm your LGTM. It has changed enough to be worth a fresh review. |
This would be a semver-major change if we were not experimental. |
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 likes it!
This changes the error handling model of ServerHttp2Stream, ServerHttp2Request and ServerHttp2Response. An 'error' emitted on ServerHttp2Stream will not go to 'uncaughtException' anymore, but to the server 'streamError'. On the stream 'error', ServerHttp2Request will emit 'abort', while ServerHttp2Response would do nothing See: nodejs#14963 PR-URL: nodejs#14991 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
Landed in 4ca8ff2 |
Sorry to report: This has broken CI. By all appearances, this should never have landed in this condition. The CI was not green. One of the tests added failed on all Windows variants. |
Windows test failure with this: not ok 202 parallel/test-http2-respond-file-404
---
duration_ms: 0.170
severity: fail
stack: |-
(node:4708) ExperimentalWarning: The http2 module is an experimental API.
assert.js:42
throw new errors.AssertionError({
^
AssertionError [ERR_ASSERTION]: 'ENOENT: no such file or directory, open \'c:\\workspace\\node-test-binary-windows\\RUN_SUBSET\\1\\VS_VERSION\\vcbt2015\\label\\ === 'ENOENT: no such file or directory, open \'./not-a-file\''
at c:\workspace\node-test-binary-windows\RUN_SUBSET\1\VS_VERSION\vcbt2015\label\win10\test\common\index.js:715:16
at c:\workspace\node-test-binary-windows\RUN_SUBSET\1\VS_VERSION\vcbt2015\label\win10\test\common\index.js:509:15
at onError (c:\workspace\node-test-binary-windows\RUN_SUBSET\1\VS_VERSION\vcbt2015\label\win10\test\parallel\test-http2-respond-file-404.js:25:9)
at ServerHttp2Stream.afterOpen (internal/http2/core.js:1704:7)
at FSReqWrap.oncomplete (fs.js:135:15) |
Reverted, so reopening so the test can be fixed and this can hopefully be re-landed soon. |
This changes the error handling model of ServerHttp2Stream, ServerHttp2Request and ServerHttp2Response. An 'error' emitted on ServerHttp2Stream will not go to 'uncaughtException' anymore, but to the server 'streamError'. On the stream 'error', ServerHttp2Request will emit 'abort', while ServerHttp2Response would do nothing See: nodejs#14963
CI: https://ci.nodejs.org/job/node-test-pull-request/9851/ (should be ok this time, please verify) cc @jasnell |
Landed as 53c5bf5. |
This changes the error handling model of ServerHttp2Stream, ServerHttp2Request and ServerHttp2Response. An 'error' emitted on ServerHttp2Stream will not go to 'uncaughtException' anymore, but to the server 'streamError'. On the stream 'error', ServerHttp2Request will emit 'abort', while ServerHttp2Response would do nothing. It also updates respondWith* to the new error handling. Fixes: #14963 PR-URL: #14991 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
This changes the error handling model of ServerHttp2Stream, ServerHttp2Request and ServerHttp2Response. An 'error' emitted on ServerHttp2Stream will not go to 'uncaughtException' anymore, but to the server 'streamError'. On the stream 'error', ServerHttp2Request will emit 'abort', while ServerHttp2Response would do nothing See: nodejs/node#14963 PR-URL: nodejs/node#14991 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
This changes the error handling model of ServerHttp2Stream, ServerHttp2Request and ServerHttp2Response. An 'error' emitted on ServerHttp2Stream will not go to 'uncaughtException' anymore, but to the server 'streamError'. On the stream 'error', ServerHttp2Request will emit 'abort', while ServerHttp2Response would do nothing. It also updates respondWith* to the new error handling. Fixes: nodejs/node#14963 PR-URL: nodejs/node#14991 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
This changes the error handling model of ServerHttp2Stream, ServerHttp2Request and ServerHttp2Response. An 'error' emitted on ServerHttp2Stream will not go to 'uncaughtException' anymore, but to the server 'streamError'. On the stream 'error', ServerHttp2Request will emit 'abort', while ServerHttp2Response would do nothing See: nodejs/node#14963 PR-URL: nodejs/node#14991 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
This changes the error handling model of ServerHttp2Stream, ServerHttp2Request and ServerHttp2Response. An 'error' emitted on ServerHttp2Stream will not go to 'uncaughtException' anymore, but to the server 'streamError'. On the stream 'error', ServerHttp2Request will emit 'abort', while ServerHttp2Response would do nothing. It also updates respondWith* to the new error handling. Fixes: nodejs/node#14963 PR-URL: nodejs/node#14991 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
This changes the error handling model of ServerHttp2Stream, ServerHttp2Request and ServerHttp2Response. An 'error' emitted on ServerHttp2Stream will not go to 'uncaughtException' anymore, but to the server 'streamError'. On the stream 'error', ServerHttp2Request will emit 'abort', while ServerHttp2Response would do nothing. It also updates respondWith* to the new error handling. Fixes: #14963 PR-URL: #14991 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
This changes the error handling model of ServerHttp2Stream, ServerHttp2Request and ServerHttp2Response. An 'error' emitted on ServerHttp2Stream will not go to 'uncaughtException' anymore, but to the server 'streamError'. On the stream 'error', ServerHttp2Request will emit 'abort', while ServerHttp2Response would do nothing. It also updates respondWith* to the new error handling. Fixes: #14963 PR-URL: #14991 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
There should be no default error handling when using Http2Stream. All errors will end up in `'streamError'` on the server anyway, but they are emitted on `'stream'` as well, otherwise some error conditions are impossible to debug. See: nodejs#14991
There should be no default error handling when using Http2Stream. All errors will end up in `'streamError'` on the server anyway, but they are emitted on `'stream'` as well, otherwise some error conditions are impossible to debug. See: #14991 PR-URL: #19232 Reviewed-By: James M Snell <[email protected]>
There should be no default error handling when using Http2Stream. All errors will end up in `'streamError'` on the server anyway, but they are emitted on `'stream'` as well, otherwise some error conditions are impossible to debug. See: nodejs#14991 PR-URL: nodejs#19232 Reviewed-By: James M Snell <[email protected]>
There should be no default error handling when using Http2Stream. All errors will end up in `'streamError'` on the server anyway, but they are emitted on `'stream'` as well, otherwise some error conditions are impossible to debug. See: nodejs#14991 PR-URL: nodejs#19232 Reviewed-By: James M Snell <[email protected]>
There should be no default error handling when using Http2Stream. All errors will end up in `'streamError'` on the server anyway, but they are emitted on `'stream'` as well, otherwise some error conditions are impossible to debug. See: #14991 Backport-PR-URL: #19478 PR-URL: #19232 Reviewed-By: James M Snell <[email protected]>
There should be no default error handling when using Http2Stream. All errors will end up in `'streamError'` on the server anyway, but they are emitted on `'stream'` as well, otherwise some error conditions are impossible to debug. See: nodejs#14991 PR-URL: nodejs#19232 Reviewed-By: James M Snell <[email protected]>
This changes the error handling model of ServerHttp2Stream,
ServerHttp2Request and ServerHttp2Response.
An 'error' emitted on ServerHttp2Stream will not go to
'uncaughtException' anymore, but to the server 'clientError'.
On the stream 'error', ServerHttp2Request will emit 'abort', while
ServerHttp2Response would do nothing
See: #14963
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
http2