lucasbru commented on code in PR #15415: URL: https://github.com/apache/kafka/pull/15415#discussion_r1500621907
########## clients/src/main/java/org/apache/kafka/clients/consumer/internals/MemberState.java: ########## @@ -132,11 +132,20 @@ public enum MemberState { PREPARE_LEAVING.previousValidStates = Arrays.asList(JOINING, STABLE, RECONCILING, ACKNOWLEDGING, UNSUBSCRIBED, FENCED); - LEAVING.previousValidStates = Arrays.asList(PREPARE_LEAVING); + // Transition from prepare leaving to leaving is the expected one in all close operations + // except for when the poll timer expires (ex. leave group due to unsubscribe or consumer + // close, where member triggers callbacks first while it continues sending heartbeat + // (PREPARE_LEAVE state) and then sends the heartbeat to leave (LEAVING state). + // All other transitions directly to LEAVING are expected when the member leaves due to + // expired poll timer. In that case, the member sends the heartbeat to leave first, and + // then invokes callbacks to release assignment while STALE, not sending any more + // heartbeats while STALE because it has been already removed from the group on the broker. + LEAVING.previousValidStates = Arrays.asList(PREPARE_LEAVING, JOINING, RECONCILING, Review Comment: What I meant was, just do `transitionToPrepareLeaving(); transitionToLeaving()`, to simplify the state machine. Then, whether we heartbeat or not would not matter. Just use an empty preparation phase, instead of skipping it entirely. But all of these are just ideas, I'll leave it to you to decide whether it's worth it or not. -- 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: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org