jsancio commented on code in PR #16900: URL: https://github.com/apache/kafka/pull/16900#discussion_r1722529849
########## raft/src/main/java/org/apache/kafka/raft/KafkaRaftClient.java: ########## @@ -666,7 +666,6 @@ private void transitionToResigned(List<ReplicaKey> preferredSuccessors) { fetchPurgatory.completeAllExceptionally( Errors.NOT_LEADER_OR_FOLLOWER.exception("Not handling request since this node is resigning")); quorum.transitionToResigned(preferredSuccessors); - maybeFireLeaderChange(); Review Comment: > If we are not notifying the RaftListener-s about the loss in leadership here, and we're not doing it in pollListeners, where do we do it? First, the raft has not lost leadership. It is resigning but staying on the same epoch. Raft stops accepting write operations while it waits for another replica to increase the epoch and win the leadership. > Or Is it the case that we do not notify about this event any more and simply let writes fail? Yeah. The next write will fail and the controller will become inactive. But raft will not increase the epoch and try to win the leadership. > Assuming a listener does not attempt a write, when will they learn about the new epoch? Once the raft client becomes a candidate in the new epoch? Yes. Once another voter increases the epoch and becomes a candidate. -- 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