varunv-cflt commented on code in PR #23174:
URL: https://github.com/apache/kafka/pull/23174#discussion_r3860105495
##########
group-coordinator/src/main/java/org/apache/kafka/coordinator/group/classic/ClassicGroupMember.java:
##########
@@ -397,16 +398,35 @@ public void setAssignment(byte[] value) {
}
/**
+ * Set the member's join future. If a join future is already pending when
a new,
+ * non-null one is set, the new request supersedes it, so the earlier one
is
+ * completed with REBALANCE_IN_PROGRESS first -- otherwise it would never
resolve
+ * on its own.
+ *
* @param value the updated join future.
*/
public void setAwaitingJoinFuture(CompletableFuture<JoinGroupResponseData>
value) {
+ if (value != null && awaitingJoinFuture != null) {
Review Comment:
I thought about it but the reorder is not straight forward for 2 reasons:
1. We will send the wrong error i.e. instead of `UNKNOWN_MEMBER_ID`, we will
send `NOT_COORDINATOR`
2. The accounting in `updateMember` will go wrong. E.g.,
`numMembersAwaitingJoinResponse` will not be decremented if we move
completeJoinFuture before `updateMember`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
