Skip to content
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

test: fix flaky test-http2-stream-destroy-event-order #31610

Closed

Conversation

addaleax
Copy link
Member

@addaleax addaleax commented Feb 1, 2020

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

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines

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
@addaleax addaleax added test Issues and PRs related to the tests. flaky-test Issues and PRs related to the tests with unstable failures on the CI. http2 Issues or PRs related to the http2 subsystem. labels Feb 1, 2020
Copy link
Member

@lundibundi lundibundi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense, good catch 👍

@jasnell
Copy link
Member

jasnell commented Feb 4, 2020

The alternative #31590 was closed in favor of this one.

@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

@addaleax addaleax added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Feb 4, 2020
@nodejs-github-bot
Copy link
Collaborator

@Trott
Copy link
Member

Trott commented Feb 6, 2020

Landed in 06a43d4

@Trott Trott closed this Feb 6, 2020
Trott pushed a commit to Trott/io.js that referenced this pull request Feb 6, 2020
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 <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
@addaleax addaleax deleted the fix-http2-stream-destroy-event-order branch February 6, 2020 14:10
codebytere pushed a commit that referenced this pull request Feb 17, 2020
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 <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
@codebytere codebytere mentioned this pull request Feb 17, 2020
codebytere pushed a commit that referenced this pull request Mar 15, 2020
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 <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
codebytere pushed a commit that referenced this pull request Mar 17, 2020
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 <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
@codebytere codebytere mentioned this pull request Mar 17, 2020
codebytere pushed a commit that referenced this pull request Mar 30, 2020
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 <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. flaky-test Issues and PRs related to the tests with unstable failures on the CI. http2 Issues or PRs related to the http2 subsystem. test Issues and PRs related to the tests.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants