...

This proposal introduces a new mechanism for explicit tracking the committed voter set tracking mechanism within the LeaderState to accurately represent . The objective is to provide an accurate representation of the last committed quorum membership.

...

A new field committedVoterStates of type Map<Integer, ReplicaState> is added to the LeaderState class. This field stores the voter states.

...

Within the maybeUpdateHighWatermark() method, once the leader advances advance the HighWatermark, the committedVoterStates map is updated to a copy of the current active currentVoterStates. This ensures the committed voter set reflects the durable state of membership at the last committed log entry.

...

The distinction between currentVoterStates (potentially changing during ongoing elections or reconfigurations) and committedVoterStates (stable, committed membership) enables clear separation of transient membership changes from those that are confirmed and durable.

...

An accessor method committedVoterStates() is provided on LeaderState to expose this value. This method is used when constructing DescribeQuorumResponse messages to include the committed voter set, improving observability and operational diagnostics.

...

The leaderState is extended to reference the KRaftControlRecordStateMachine, from which derives the high watermark. Using this information the committed voter set can be obtained directly from KRaftControlRecordStateMachine. Both the voter set in the KRaftControlRecordStateMachine and the high watermark are maintained entirely in memory. This eliminates disk I/O, there by, minimizing performance impact.

Semantic

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

1. Committed voter present in voters or observers
   • If committed voter also exists in the voters or observer set, its ReplicaState is identical to the corresponding entry in that set.
   • All field within the ReplicaState are fully available.
2. Committed voter absent from voters or observers 

   • If a committed voter does not exist in either voters or observers, the following fields in its ReplicaState are assigned sentinel values:

     • endLogOffset = -1

     • lastFetchTimestamp = -1

     • lastCaughtUpTimestamp = -1

   • These fields above are help users to know the current voter set information and its not help user to understand committed voter status so we can allow them to be sentinel value.

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.

Compatibility, Deprecation, and Migration Plan

• Update Bump DescribeQuorumRequest and DescribeQuorumResponse to a newer version, with backward compatibility preserved for the old protocol version.

...

Unit test and integration test will be added.

Rejected Alternatives

If there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other wayA new field, state, can be introduced within the ReplicaState structure to explicitly track the committed status of the voter.