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

http2: fix end without read #20621

Closed

Conversation

apapirovski
Copy link
Member

Adjust http2 behaviour to allow ending a stream even after some
data comes in (when the user has no intention of reading that
data). Also correctly end a stream when trailers are present.

Fixes: #20060

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

Adjust http2 behaviour to allow ending a stream even after some
data comes in (when the user has no intention of reading that
data). Also correctly end a stream when trailers are present.
@apapirovski apapirovski added the http2 Issues or PRs related to the http2 subsystem. label May 9, 2018
@nodejs-github-bot nodejs-github-bot added the lib / src Issues and PRs related to general changes in the lib or src directory. label May 9, 2018
@apapirovski
Copy link
Member Author

CI: https://ci.nodejs.org/job/node-test-pull-request/14731/

/cc @nodejs/http2

Copy link
Member

@jasnell jasnell left a comment

Choose a reason for hiding this comment

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

LGTM, would like @mcollina to review also :-)

@jasnell jasnell requested a review from mcollina May 9, 2018 17:23
@apapirovski
Copy link
Member Author

@mcollina since @jasnell requested your review, could you have a look? Thanks!

Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

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

LGTM

@trivikr trivikr added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label May 16, 2018
stream.read(0);
}
if (!stream[kState].didRead && !stream._readableState.resumeScheduled)
stream.resume();
Copy link
Member

Choose a reason for hiding this comment

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

this is slightly different than read(0). Can you please explain why this is needed?
I would prefer if we didn't use _readableState here.

Copy link
Member Author

Choose a reason for hiding this comment

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

This is equivalent to what we do in http and is needed because in cases where the user doesn't intend to consume the data (indicated by never having read and not having a pending resume call), we still want to be able to properly destroy the stream.

Copy link
Member

Choose a reason for hiding this comment

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

Can you please add a comment about this?

Copy link
Member Author

Choose a reason for hiding this comment

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

Will do later today.

state.didRead = true;
this[kStream].on('data', onStreamData);
} else {
process.nextTick(resumeStream, this[kStream]);
Copy link
Member

Choose a reason for hiding this comment

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

I don't think the nextTick is needed here, as resume() happens in a nextTick anyway.

Copy link
Member Author

Choose a reason for hiding this comment

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

That part is carried over from before (didn't change) and used to definitely be necessary. We have a test for it even which breaks otherwise: parallel/test-http2-compat-serverrequest-pipe.

Copy link
Member Author

Choose a reason for hiding this comment

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

You could probably have a look at the git blame for the line to find the corresponding PR.

Copy link
Member Author

Choose a reason for hiding this comment

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

See #15503 — I don't fully recall where exactly we have an async call to pause but we do somewhere.

Copy link
Member

@mcollina mcollina May 16, 2018

Choose a reason for hiding this comment

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

It's probably something we would have to look into. It's a pretty old one: #15702.

@trivikr trivikr removed the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label May 17, 2018
@apapirovski apapirovski added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label May 17, 2018
@apapirovski
Copy link
Member Author

Updated with the requested comment. Will be landing this later today.

@apapirovski
Copy link
Member Author

Landed in 8d38288. Thanks everyone!

@apapirovski apapirovski deleted the fix-http2-end-without-read branch May 17, 2018 14:00
apapirovski added a commit that referenced this pull request May 17, 2018
Adjust http2 behaviour to allow ending a stream even after some
data comes in (when the user has no intention of reading that
data). Also correctly end a stream when trailers are present.

PR-URL: #20621
Fixes: #20060
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
@addaleax
Copy link
Member

@apapirovski I think there’s a pretty high chance this is the cause of CI failures like these, given that this occurred somewhat frequently only today and this PR touched the test: https://ci.nodejs.org/job/node-test-commit-linuxone/1405/nodes=rhel72-s390x/testReport/junit/(root)/test/parallel_test_http2_client_upload_reject/

@BridgeAR
Copy link
Member

@addaleax I do not think that this is the cause of these issues. We have these failures since a couple of days and this PR just landed very recently.

@BridgeAR
Copy link
Member

See #20750

@addaleax
Copy link
Member

@BridgeAR Locally, for that specific test (which is not mentioned in the issue), I get:

  • a 25/1000 failure rate on master
  • a 19/1000 failure rate for the commit in which this PR landed, and
  • a 0/1000 failure rate for its parent.

That makes me somewhat confident that this PR is in fact the cause of what we’ve been seeing today?

@BridgeAR
Copy link
Member

I just had another look into it and you are right! I opened a revert #20832

MylesBorins pushed a commit that referenced this pull request May 22, 2018
Adjust http2 behaviour to allow ending a stream even after some
data comes in (when the user has no intention of reading that
data). Also correctly end a stream when trailers are present.

PR-URL: #20621
Fixes: #20060
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
@addaleax addaleax mentioned this pull request May 22, 2018
kjin pushed a commit to kjin/node that referenced this pull request Aug 23, 2018
Adjust http2 behaviour to allow ending a stream even after some
data comes in (when the user has no intention of reading that
data). Also correctly end a stream when trailers are present.

PR-URL: nodejs#20621
Fixes: nodejs#20060
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
kjin pushed a commit to kjin/node that referenced this pull request Sep 19, 2018
Adjust http2 behaviour to allow ending a stream even after some
data comes in (when the user has no intention of reading that
data). Also correctly end a stream when trailers are present.

PR-URL: nodejs#20621
Fixes: nodejs#20060
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
kjin pushed a commit to kjin/node that referenced this pull request Oct 16, 2018
Adjust http2 behaviour to allow ending a stream even after some
data comes in (when the user has no intention of reading that
data). Also correctly end a stream when trailers are present.

PR-URL: nodejs#20621
Fixes: nodejs#20060
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
BethGriggs pushed a commit that referenced this pull request Oct 17, 2018
Adjust http2 behaviour to allow ending a stream even after some
data comes in (when the user has no intention of reading that
data). Also correctly end a stream when trailers are present.

Backport-PR-URL: #22850
PR-URL: #20621
Fixes: #20060
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
@BethGriggs BethGriggs mentioned this pull request Oct 30, 2018
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. http2 Issues or PRs related to the http2 subsystem. lib / src Issues and PRs related to general changes in the lib or src directory.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

difference between http2 Compatibility API and http
7 participants