KAFKA-13940; Return NOT_LEADER_OR_FOLLOWER if DescribeQuorum sent to non-leader#12517
Merged
hachikuji merged 2 commits intoapache:trunkfrom Aug 17, 2022
Merged
KAFKA-13940; Return NOT_LEADER_OR_FOLLOWER if DescribeQuorum sent to non-leader#12517hachikuji merged 2 commits intoapache:trunkfrom
hachikuji merged 2 commits intoapache:trunkfrom
Conversation
dajac
reviewed
Aug 16, 2022
Member
dajac
left a comment
dajac
left a comment
There was a problem hiding this comment.
Thanks for the patch. Left a small comment for consideration.
dajac
approved these changes
Aug 16, 2022
Member
dajac
left a comment
dajac
left a comment
There was a problem hiding this comment.
LGTM, assuming tests pass. Thanks!
dengziming
reviewed
Aug 17, 2022
|
|
||
| if (!quorum.isLeader()) { | ||
| return DescribeQuorumRequest.getTopLevelErrorResponse(Errors.INVALID_REQUEST); | ||
| return DescribeQuorumResponse.singletonErrorResponse( |
Member
There was a problem hiding this comment.
We have documentation comments for handleFetchRequest and other handleXXXRequest methods, how about adding documentation comments for handleDescribeQuorumRequest.
Contributor
Author
There was a problem hiding this comment.
Hmm, this part at least seems self-explanatory. Do you see something else that deserves more explanation? Would you mind submitting a follow-up PR if you do? I am happy to review.
3 tasks
hachikuji
added a commit
that referenced
this pull request
Aug 17, 2022
…non-leader (#12517) Currently the server will return `INVALID_REQUEST` if a `DescribeQuorum` request is sent to a node that is not the current leader. In addition to being inconsistent with all of the other leader APIs in the raft layer, this error is treated as fatal by both the forwarding manager and the admin client. Instead, we should return `NOT_LEADER_OR_FOLLOWER` as we do with the other APIs. This error is retriable and we can rely on the admin client to retry it after seeing this error. Reviewers: David Jacot <djacot@confluent.io>
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
Currently the server will return
INVALID_REQUESTif aDescribeQuorumrequest is sent to a node that is not the current leader. In addition to being inconsistent with all of the other leader APIs in the raft layer, this error is treated as fatal by both the forwarding manager and the admin client. Instead, we should returnNOT_LEADER_OR_FOLLOWERas we do with the other APIs. This error is retriable and we can rely on the admin client to retry it after seeing this error.Note that we could also check for this error in
ForwardingManagerand retry the request from that context, but the current forwarding logic is only setup to handle retries for requests sent to the controller, which is logically distinct from the raft leader. TheDescribeQuorumis a bit of an oddball from an API perspective because it is a multi-partition request, but it is always forwarded to the controller since there is only one raft partition. So to handle this case specially, we would have to unwrap the envelope and check the error for the __cluster_metadata partition. It seemed simpler to rely on the admin client to retry.Committer Checklist (excluded from commit message)