-
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
flaky: parallel/test-http2-*
on Windows
#20750
Comments
This happens as a result of the recent change to destroy the socket properly but it might be revealing an actual bug rather than just being a flaky test. That test does a pretty basic pipe operation, it shouldn't ever trigger an ECONNRESET. ping @nodejs/http2 |
This also just happened in |
For posterity (since the link provided by @apapirovski will eventually 404): not ok 231 parallel/test-http2-client-upload
---
duration_ms: 0.220
severity: fail
exitcode: 1
stack: |-
(node:2492) ExperimentalWarning: The http2 module is an experimental API.
events.js:167
throw er; // Unhandled 'error' event
^
Error: read ECONNRESET
at TCP.onread (net.js:658:25)
Emitted 'error' event at:
at emitErrorNT (internal/streams/destroy.js:82:8)
at emitErrorAndCloseNT (internal/streams/destroy.js:50:3)
at process._tickCallback (internal/process/next_tick.js:63:19)
... Host: test-azure_msft-win2016-x64-2 The fact that it's happening on both Azure and Rackspace, win2008 and win2016, seems to suggest (to me at least) a bug in Node.js or a dependency like libuv. |
Pretty sure it's because we use |
The bug on pipe happens on a mac too. |
@mcollina I can't seem to replicate on mine :( This is what I run it with: |
I also can't replicate on macOS nor do I see instances looking through macOS failures in Ci. It may very well be a bug on macOS too, but if so, we're definitely seeing it with much greater frequency on Windows in CI. |
I'm testing a possible fix in https://ci.nodejs.org/job/node-stress-single-test/1845/ and https://ci.nodejs.org/job/node-test-commit-windows-fanned/18023/ |
On my system. |
Currently http2 does not properly submit GOAWAY frames when a session is being destroyed. It also doesn't properly handle when the other party severs the connection after sending a GOAWAY frame, even though it should. Edge, IE & Safari are currently unable to handle empty TRAILERS frames despite them being correctly to spec. Instead send an empty DATA frame with END_STREAM flag in those situations. Fix and adjust several flaky and/or incorrect tests. PR-URL: #20772 Fixes: #20705 Fixes: #20750 Fixes: #20850 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: James M Snell <[email protected]>
It's possible for the connections to take too long and since the server is already unrefed, the process will just exit. Instead adjust the test so that server unref only happens after all sessions have been successfuly established and unrefed. That still tests the same condition but will not fail under load. PR-URL: #20772 Fixes: #20705 Fixes: #20750 Fixes: #20850 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: James M Snell <[email protected]>
Currently http2 does not properly submit GOAWAY frames when a session is being destroyed. It also doesn't properly handle when the other party severs the connection after sending a GOAWAY frame, even though it should. Edge, IE & Safari are currently unable to handle empty TRAILERS frames despite them being correctly to spec. Instead send an empty DATA frame with END_STREAM flag in those situations. Fix and adjust several flaky and/or incorrect tests. PR-URL: #20772 Fixes: #20705 Fixes: #20750 Fixes: #20850 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: James M Snell <[email protected]>
It's possible for the connections to take too long and since the server is already unrefed, the process will just exit. Instead adjust the test so that server unref only happens after all sessions have been successfuly established and unrefed. That still tests the same condition but will not fail under load. PR-URL: #20772 Fixes: #20705 Fixes: #20750 Fixes: #20850 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: James M Snell <[email protected]>
It's back. /ping @apapirovski Host: test-rackspace-win2008r2-x64-4 not ok 252 parallel/test-http2-pipe
---
duration_ms: 0.274
severity: fail
exitcode: 1
stack: |-
(node:5876) ExperimentalWarning: The http2 module is an experimental API.
events.js:167
throw er; // Unhandled 'error' event
^
Error: read ECONNRESET
at TCP.onread (net.js:657:25)
Emitted 'error' event at:
at emitErrorNT (internal/streams/destroy.js:82:8)
at emitErrorAndCloseNT (internal/streams/destroy.js:50:3)
at process._tickCallback (internal/process/next_tick.js:63:19)
... |
Wait for close event on server stream before shuting down server and client to avoid races seen on windows CI. Refs: nodejs#20750 (comment)
Wait for close event on server stream before shuting down server and client to avoid races seen on windows CI. Refs: #20750 (comment) PR-URL: #29889 Refs: #29852 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: James M Snell <[email protected]>
Wait for close event on server stream before shuting down server and client to avoid races seen on windows CI. Refs: #20750 (comment) PR-URL: #29889 Refs: #29852 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: James M Snell <[email protected]>
Wait for close event on server stream before shuting down server and client to avoid races seen on windows CI. Refs: #20750 (comment) PR-URL: #29889 Refs: #29852 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: James M Snell <[email protected]>
Alternative to nodejs#31590. It appears that the issue here is that the test falsely assumed that closing the client (which also currently destroys the socket rather than gracefully shutting down the connection) would still leave enough time for the server side to receive the stream error. Address that by explicitly waiting for the server side to receive the stream error before closing the client and the connection with it. Refs: nodejs#31590 Refs: nodejs#20750
Wait for close event on server stream before shuting down server and client to avoid races seen on windows CI. Refs: #20750 (comment) PR-URL: #29889 Refs: #29852 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: James M Snell <[email protected]>
Alternative to nodejs#31590. It appears that the issue here is that the test falsely assumed that closing the client (which also currently destroys the socket rather than gracefully shutting down the connection) would still leave enough time for the server side to receive the stream error. Address that by explicitly waiting for the server side to receive the stream error before closing the client and the connection with it. Refs: nodejs#31590 Refs: nodejs#20750 PR-URL: nodejs#31610 Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Denys Otrishko <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Rich Trott <[email protected]>
Alternative to #31590. It appears that the issue here is that the test falsely assumed that closing the client (which also currently destroys the socket rather than gracefully shutting down the connection) would still leave enough time for the server side to receive the stream error. Address that by explicitly waiting for the server side to receive the stream error before closing the client and the connection with it. Refs: #31590 Refs: #20750 PR-URL: #31610 Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Denys Otrishko <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Rich Trott <[email protected]>
Alternative to #31590. It appears that the issue here is that the test falsely assumed that closing the client (which also currently destroys the socket rather than gracefully shutting down the connection) would still leave enough time for the server side to receive the stream error. Address that by explicitly waiting for the server side to receive the stream error before closing the client and the connection with it. Refs: #31590 Refs: #20750 PR-URL: #31610 Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Denys Otrishko <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Rich Trott <[email protected]>
Alternative to #31590. It appears that the issue here is that the test falsely assumed that closing the client (which also currently destroys the socket rather than gracefully shutting down the connection) would still leave enough time for the server side to receive the stream error. Address that by explicitly waiting for the server side to receive the stream error before closing the client and the connection with it. Refs: #31590 Refs: #20750 PR-URL: #31610 Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Denys Otrishko <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Rich Trott <[email protected]>
Alternative to #31590. It appears that the issue here is that the test falsely assumed that closing the client (which also currently destroys the socket rather than gracefully shutting down the connection) would still leave enough time for the server side to receive the stream error. Address that by explicitly waiting for the server side to receive the stream error before closing the client and the connection with it. Refs: #31590 Refs: #20750 PR-URL: #31610 Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Denys Otrishko <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Rich Trott <[email protected]>
It hasn't failed in a long time. Refs: nodejs#20750
It hasn't failed for a long time. Closes: nodejs#20750
It hasn't failed for a long time. Closes: nodejs#20750 PR-URL: nodejs#37631 Fixes: nodejs#20750 Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Ruy Adorno <[email protected]>
It hasn't failed in a long time. Refs: #20750 PR-URL: #37631 Fixes: #20750 Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Ruy Adorno <[email protected]>
It hasn't failed for a long time. Closes: #20750 PR-URL: #37631 Fixes: #20750 Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Ruy Adorno <[email protected]>
It hasn't failed in a long time. Refs: #20750 PR-URL: #37631 Fixes: #20750 Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Ruy Adorno <[email protected]>
It hasn't failed for a long time. Closes: #20750 PR-URL: #37631 Fixes: #20750 Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Ruy Adorno <[email protected]>
@nodejs/build @nodejs/platform-windows @nodejs/testing @nodejs/http2
[refack: edited info and added link to test file]
The text was updated successfully, but these errors were encountered: