...

Proposed Changes

Raft State Tracking

This proposal introduces a new committed voter set tracking mechanism within the LeaderState to accurately represent the last committed quorum membership.

• A new field committedVoterStates of type Map<Integer, ReplicaState> is added to the LeaderState class. This field stores the snapshot of the voter states that have been durably committed in the Raft log.

• Within the maybeCommitToLeaderStatemaybeUpdateHighWatermark() method (or equivalent commit processing logic), once the commit index advances and a quorum is confirmed for the new offsetleader 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 snapshotvalue. This method is used when constructing DescribeQuorumResponse messages to include the committed voter set, improving observability and operational diagnostics.

• In some cases, like quorum startup and fetch snapshots, we can't get the value of committedVoterStates, at that case, we should read committed voter from replicatedLog with epochStartOffset but there is no information for logEndOffset, lastFetchTimestamp and lastCaughtUpTimestamp so they will return default value(-1).

This mechanism strengthens the Raft membership model by making committed membership explicit and accessible to tooling and clients, thereby improving cluster state transparency.

Compatibility, Deprecation, and Migration Plan

...