-
Notifications
You must be signed in to change notification settings - Fork 1.6k
gRPC: fix bugs found during testing #2039
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
Merged
Merged
Changes from 3 commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
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.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is in line to what gRPC folks described:
The crash I saw happened when there were two calls to
GenericClientAsyncReaderWriter::Finish
. I'm not 100% sure, but one way it could happen is if network connectivity changed in-betweenOnOperationFailed
andOnFinishedByServer
(which is line to how I ran into this, trying to switch off network randomly):OnOperationFailed
. At this point, the read is already removed fromcompletions_
, but the write is still there;OnOperationFailed
callsFinish
on the gRPC call. The write is still on the completion queue;OnFinishedByServer
, network connectivity changes, which invokesFinishAndNotify
on this stream;FinishAndNotify
invokesShutdown
, which noticescompletions_
are not empty (there is still that write there), which it takes as a signal to callFinish
on the gRPC call. However, this call has already been finished, which triggers an assertion failure in gRPC.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can see what you mean. In general performing all operations on the async queue should help alleviate the need for this kind of reasoning, but that's hard to do down here.
At the higher level we impose the restriction that callbacks are only honored if they were fired before a major state transition. Such a strategy doesn't work well for listeners registered to get callbacks indefinitely. An alternative is to ensure that routines called by the network monitor are idempotent.
If I'm reading correctly it seems that the latter is what you've done here. I'm down with that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I think so. The new logic is that before
Finish
is invoked on the gRPC call, pending completions are always drained. BecauseFinish
is a no-op when there are no completions, it effectively does makeFinish
idempotent.