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

netty: improve server handling of writes to reset streams #10258

Merged
merged 4 commits into from
Feb 16, 2024

Conversation

benjaminp
Copy link
Contributor

A server stream can be reset by the client while server writes are still queued. After the stream is reset, the netty connection will forget the stream object. The NettyServerHandler must deal with that situation. sendResponseHandlers already had some code to do that. This change standardizes that code and adds it to sendGrpcFrame. This fixes a potential bug where a SendGrpcFrameCommand with endOfStream=true would raise an AssertionError if written to a reset stream. (This bug is not currently reachable because endOfStream=false for all server SendGrpcFrameCommand objects.)

A server stream can be reset by the client while server writes are still queued. After the stream is reset, the netty connection will forget the stream object. The `NettyServerHandler` must deal with that situation. `sendResponseHandlers` already had some code to do that. This change standardizes that code and adds it to `sendGrpcFrame`. This fixes a potential bug where a `SendGrpcFrameCommand` with `endOfStream=true` would raise an `AssertionError` if written to a reset stream. (This bug is not currently reachable because `endOfStream=false` for all server `SendGrpcFrameCommand` objects.)
Copy link
Member

@ejona86 ejona86 left a comment

Choose a reason for hiding this comment

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

Looks like this slipped through the cracks. I'm sorry it didn't see movement earlier.

I'm definitely a fan of passing around Http2Stream instead of integers that then require lookups.

I made one comment. I don't mind making the change if you are no longer interested.

@ejona86
Copy link
Member

ejona86 commented Feb 15, 2024

Looks like #10384 did something related. Although that change still assumes requireHttp2Stream succeeds. This seems even better.

@ejona86 ejona86 added the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label Feb 15, 2024
@grpc-kokoro grpc-kokoro removed the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label Feb 15, 2024
@benjaminp benjaminp force-pushed the improve-reset-handling branch 3 times, most recently from d861527 to 58a6f83 Compare February 16, 2024 00:35
Copy link
Member

@ejona86 ejona86 left a comment

Choose a reason for hiding this comment

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

Thank you much. I wasn't expecting you to be so responsive after we were very-much-so-not-responsive!

@ejona86
Copy link
Member

ejona86 commented Feb 16, 2024

@larry-safran, looks like the CI is broken due to a semantic merge conflict with the Multichild cleanup PR.

@ejona86 ejona86 added the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label Feb 16, 2024
@grpc-kokoro grpc-kokoro removed the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label Feb 16, 2024
@larry-safran larry-safran merged commit a68399a into grpc:master Feb 16, 2024
14 checks passed
@benjaminp benjaminp deleted the improve-reset-handling branch February 16, 2024 19:13
@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 17, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants