...

The relationship between voters and committed voters is defined as follows:

Committed voter present in voters/observers
If a committed voter is also present in the current voters or observers set, its ReplicaState is identical to the corresponding entry in those sets. This ensures that all runtime fields within ReplicaState are available.Committed voter absent from voters or observers 

Committed voter absent from voters or observers
If a committed voter is not found in either voters or observers, certain runtime-specific fields cannot be derived, since the replica is no longer actively participating in log replication. To maintain schema consistency, these fields in its ReplicaState are set to sentinel values:

• endLogOffset = -1

• lastFetchTimestamp = -1

• lastCaughtUpTimestamp = -1

These fields are only meaningful for active replicas in the quorum. For committed voters, they are not strictly required—the sentinel values simply indicate that the data is unavailable or not applicable.

Benefit

This mechanism strengthens the Raft membership model by:

• Making committed membership explicit.

• Providing a consistent interface for tooling and client introspection.

• Improving the overall transparency and debuggability of the cluster state.

• Reducing performance overhead by avoiding disk operations, since all required voter state and high watermark data are memory-resident.

Case Study: Voter Status Scenarios

When considering voter status, the following scenarios should be addressed:

1. An existing cluster

   • This is the most common scenario.

   • The cluster already contains a snapshot that includes the voter set record.

   • In this case, voters can be retrieved directly from the KRaftControlStateMachine.

2. A Single Node Initialized with Dynamic Voters
   

   • After initialization, the node generates a 0-0.checkpoint file.

   • Similar to the existing cluster case, voters can be obtained directly from the checkpoint through the KRaftControlStateMachine.

3. A Single Node Initialized with Static Voters
   

   • This is a special case that requires additional handling.

   • A flag hasHistoryUpdated is introduced to VoterSetHistory, with its initial value set to false.

   • When the votersHistory is updated, this flag is set to true.

   • Retrieval logic:

     • If hasHistoryUpdated is true, the voter set is returned from votersHistory.

     • If hasHistoryUpdated is false, the static voter set is returned.

Compatibility, Deprecation, and Migration Plan

...