kevin-wu24 commented on code in PR #18304:
URL: https://github.com/apache/kafka/pull/18304#discussion_r1924296931
##########
raft/src/main/java/org/apache/kafka/raft/KafkaRaftClient.java:
##########
@@ -682,13 +690,15 @@ private void transitionToCandidate(long currentTimeMs) {
private void transitionToUnattached(int epoch) {
quorum.transitionToUnattached(epoch);
maybeFireLeaderChange();
+ kafkaRaftMetrics.removeLeaderMetrics();
resetConnections();
}
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);
+ kafkaRaftMetrics.removeLeaderMetrics();
Review Comment:
~I think the call below in `onBecomeFollower` is not necessary. Leader state
can only transition to Unattached or Resigned~
Never mind, looks like leader -> follower transition with a higher epoch
bump is possible during partitioning scenarios (i.e.
RaftEventSimulationTest#canMakeProgressAfterBackToBackLeaderFailures). This
case is not mentioned on the transition chart in `QuorumState`.
--
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
