[call-v3] Add client half close event edge to filters #36598
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Automated fix for refs/heads/master
Automated fix for refs/heads/transport-refs
ctiller
added
the
release notes: no
grpc-checks
bot
added
bloat/low
per-call-memory/neutral
per-channel-memory/neutral
labels
grpc-checks
bot
added
per-call-memory/decrease
and removed
per-call-memory/neutral
labels
markdroth
approved these changes
May 14, 2024
| @@ -43,6 +43,7 @@ | |||
| // - OnServerInitialMetadata - $VALUE_TYPE = ServerMetadata | |||
| // - OnServerToClientMessage - $VALUE_TYPE = Message | |||
| // - OnClientToServerMessage - $VALUE_TYPE = Message | |||
| // - OnClientToServerHalfClose - no value | |||
There was a problem hiding this comment.
I thought we were just going to call this OnClientHalfClose? That's what we put in the internal doc we wrote for estubs.
grpc-checks
bot
added
per-call-memory/neutral
and removed
per-call-memory/decrease
labels
grpc-checks
bot
added
per-call-memory/decrease
and removed
per-call-memory/neutral
labels
copybara-service bot
pushed a commit
that referenced
this pull request
May 20, 2024
Right now there's no ordering between the set context from the SetCall callback chain in server.cc, and the read context a few lines down from the new if statement inserted here -- that is if a call is cancelled whilst the server is initializing the context we see a tsan race. Until #36598 this was a non-issue however because we were entirely discarding the cancellation edge. Now that we've gotten that back again, this race is appearing. I'd like us to fix this properly, but to do so probably needs some deeper work on what contexts are and how they're initialized -- and that's not for this week (but maybe this month). ---- DO NOT SUBMIT. This PR is for testing purposes only. [cl/635328547](http://cl/635328547) PiperOrigin-RevId: 635328547
copybara-service bot
pushed a commit
that referenced
this pull request
May 20, 2024
Right now there's no ordering between the set context from the SetCall callback chain in server.cc, and the read context a few lines down from the new if statement inserted here -- that is if a call is cancelled whilst the server is initializing the context we see a tsan race. Until #36598 this was a non-issue however because we were entirely discarding the cancellation edge. Now that we've gotten that back again, this race is appearing. I'd like us to fix this properly, but to do so probably needs some deeper work on what contexts are and how they're initialized -- and that's not for this week (but maybe this month). ---- DO NOT SUBMIT. This PR is for testing purposes only. [cl/635328547](http://cl/635328547) PiperOrigin-RevId: 635328547
copybara-service bot
pushed a commit
that referenced
this pull request
May 21, 2024
#36598 made a change to the logging filter which required `CallTracerAnnotationInterface` to always be present on the call. That is only the case when metrics/tracing is enabled, which is not always the case. Also, modify the test to test that logging works even if metrics/tracing is not enabled. Internal ref - b/341794662 Closes #36671 COPYBARA_INTEGRATE_REVIEW=#36671 from yashykt:FixLogging 4f736e7 PiperOrigin-RevId: 635610705
copybara-service bot
pushed a commit
that referenced
this pull request
May 22, 2024
Right now there's no ordering between the set context from the SetCall callback chain in server.cc, and the read context a few lines down from the new if statement inserted here -- that is if a call is cancelled whilst the server is initializing the context we see a tsan race. Until #36598 this was a non-issue however because we were entirely discarding the cancellation edge. Now that we've gotten that back again, this race is appearing. I'd like us to fix this properly, but to do so probably needs some deeper work on what contexts are and how they're initialized -- and that's not for this week (but maybe this month). PiperOrigin-RevId: 636295078
jdcormie
pushed a commit
to jdcormie/grpc
that referenced
this pull request
May 24, 2024
Right now there's no ordering between the set context from the SetCall callback chain in server.cc, and the read context a few lines down from the new if statement inserted here -- that is if a call is cancelled whilst the server is initializing the context we see a tsan race. Until grpc#36598 this was a non-issue however because we were entirely discarding the cancellation edge. Now that we've gotten that back again, this race is appearing. I'd like us to fix this properly, but to do so probably needs some deeper work on what contexts are and how they're initialized -- and that's not for this week (but maybe this month). PiperOrigin-RevId: 636295078
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.