I think the terminology may be causing some confusion here. The "granting" voters are those who have voted for the leader and which the leader is using as the basis of its election. The "endorsing" voters are those who have acknowledged the leader. The set of endorsing voters changes over time as the voters convert to followers and begin fetching. We use nonEndorsingVoters to know which voters still need to be sent BeginQuorumEpoch. Note that it is possible for a voter to have granted a vote, but not yet endorsed the election (because it does not know the vote succeeded).

We should not conflate these sets, but maybe we can come up with better terms to avoid the confusion. I would stick with "granting" voters as the set of voters who granted the leader's candidacy. However, maybe we can change "endorsing" to "acknowledged"? These are the voters who have acknowledged the election result. What do you think?

Yeah that makes sense. As you explained, endorsing are those voters who have acknowledged the BeginQuorumEpoch request from the leader, so eventually if the leader is accepted, this set will be all the voters who voted.
Regarding endorsing v/s acknowledged, can we also add what has been acknowledged? Like, endoresedQuorumEpoch or endorsedLeaderCandidacy or something like this. Just adding context, might clear the confusion. WDYT @hachikuji , @jsancio

Good to know the subtle difference. "acknowledged" sounds good to me.

Ok. I will change it to acknowledged then..

@jsancio , going by all the discussions here, I needed to revert some of the changes you had suggested in #9539 (comment) as a couple of test cases were failing. The issue is on this line:

https://github.com/apache/kafka/blob/ce275e29beb48611425708fbe67d28d17329845a/raft/src/main/java/org/apache/kafka/raft/LeaderState.java#L52

Note that, this is a deviation from the original code which was:

boolean hasEndorsedLeader = voterId == localId;

and the test case which was failing because of this was this line in particular:

https://github.com/apache/kafka/pull/9539/files#diff-01c9950503611c357b85ef5b8850d2fbc6060075ce028bf4f86dfc6cbd63fd3cR255

Reason being, when transitionToLeader is invoked from QuorumState upon becoming the leader, it passes in the set of granting voters. Keeping in mind the explanation provided by @hachikuji above, these are all the voters who voted for the current leader.

If you check the above erroneous condition, we are checking if a voter has endorsed the voting by checking if it is present in the granting voters list:

boolean hasEndorsedLeader = grantingVoters.contains(voterId);

So, the problem is, this condition will force all voters to be considered as having endorsed the Leader even before the BeginQuorumEpoch request response dance has begun.

The test cases in question fails because the pollLeader() method in KafkaRaftClient, checks the nonEndorsingVoters and sends the BeginQuorumEpoch request to nonEndorsed ones here:

long timeUntilSend = maybeSendRequests(
            currentTimeMs,
            state.nonEndorsingVoters(),
            this::buildBeginQuorumEpochRequest
        );

but it never gets to do that because every granting voter has been marked as an endorsed voter.

Lastly, we don't really need the acknowledgedVoters here because all we need are the granting voters in the LeaderChangeMessage i.e the voters who voted for the Leader in the current epoch.

So, I am reverting the changes and now, the test cases have all passed as well. There were some timeout related errors as well which I believe which got resolved as well.