I updated the KIP to include the information discussed in this thread. I updated the sections "Reference explanation / Endpoints information" and "Reference explanation / Leader election".
On Sun, Feb 11, 2024 at 1:06 PM José Armando García Sancio <jsan...@confluent.io> wrote: > Great examples. The short answer is that yes, the leader needs to keep > sending a BeingQuorumEpoch to a voter until the voter acknowledges it. > In the current KRaft implementation, the KRaft leader already does > this (the set of unacknowledged voters is tracked in > LeaderState::nonAcknowledgeVoters and it used to send the > BeginQuorumEpoch RPC). The leader continues to send the > BeginQuorumEpoch RPC until a voter has acknowledged it. When the voter > handles the BeginQuorumEpoch, it first persists the leader id, leader > uuid (new in this KIP) and leader epoch to the quorum-state file > before replying to the RPC. Since the leader's state is persisted > before replying to the BeginQuorumEpoch RPC, one RPC and > acknowledgement is enough. Note that if a replica loses its disk and > quorum state it will come back with a different replica uuid and won't > be part of the quorum. This explanation is not entirely correct with this KIP since the leader's endpoint is not persisted when handling the BeginQuorumEpoch RPC. You are correct that the leader needs to send BeginQuorumEpoch requests to any voter that is not sending Fetch and FetchSnapshot requests. I included this information in the "Reference explanation / Leader election". Thanks, -- -José
