This page is meant as a template for writing a KIP. To create a KIP choose Tools->Copy on this page and modify with your content and replace the heading with the next KIP number and a description of your issue. Replace anything in italics with your own description.

Status

Current state: Draft

...

By maintaining a separate committedVoterSet, the system ensures:

• Safety: Quorum checks and leader decisions are based on a membership configuration that is guaranteed to be replicated and agreed upon by a majority.

• Stability: The committed voter set changes only at commit points, avoiding transient or rolled-back configurations.

• Correctness under Reconfiguration: Both during joint consensus transitions and simple add/remove operations, the system preserves Raft’s safety guarantees.

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.

Public Interfaces

Request Schema

• Both committed and uncommitted voters participate in quorum decisions and elections. However, uncommitted voters (those whose VotersRecord has been appended but not yet committed) carry a risk: if the leader crashes before the VotersRecord is committed, the voter change maybe lost due to log truncation, leading to potential configuration inconsistencies.

• Stability: When the committed and uncommitted voter sets differ, the cluster is in a joint consensus phase.
  Exposing this state allows management and orchestration systems to recognize that the controller quorum is undergoing a transitional reconfiguration, and to avoid assuming the new configuration is already stable.

• Debugging and Compliance Verification: During troubleshooting or post-incident audits, operators and tools must be able to differentiate between committed voters and uncommitted voters that have started replicating but are not yet officially part of the quorum.This distinction is critical for confirming whether a reconfiguration completed successfully and whether the cluster’s control plane reached a consistent state.

Public Interfaces

Request Schema

{
  "apiKey": 55,
  "type": "request",
  "listeners": ["broker", "controller"],
  "name": "DescribeQuorumRequest",
  // Version 1 adds additional fields in the response. The request is unchanged (KIP-836).
  // Version 2 adds additional fields in the response. The request is unchanged (KIP-853).
+ // Version 3 adds additional fields in the response. The request is unchanged.
+ "validVersions": "0-3",
  "flexibleVersions": "0+",
  "latestVersionUnstable": false,
  "fields": [
    { "name": "Topics", "type": "[]TopicData", "versions": "0+",
      "about": "The topics to describe.", "fields": [
      { "name": "TopicName", "type": "string", "versions": "0+", "entityType": "topicName",
        "about": "The topic name." },
      { "name": "Partitions", "type": "[]PartitionData", "versions": "0+",
        "about": "The partitions to describe.", "fields": [
        { "name": "PartitionIndex", "type": "int32", "versions": "0+",
          "about": "The partition index." }
      ]
      }]
    }
  ]
}

...

The leaderState is extended to reference the KRaftControlRecordStateMachine, from which derives the high watermarkvoter set history. Using this information the of high watermark from LeaderState, 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, and minimizing performance impact.

Scenario

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(voter) in the quorum. For committed voters, they are not strictly required—the sentinel values simply indicate that the data is unavailable or not applicable.

Case Study: Voter Status Scenarios

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

...

• 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.

...

• 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.

current 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 and reflect the current replica state.

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:

• hasAcknowledgedLeader = false

• endLogOffset = -1

• lastFetchTimestamp = -1

• lastCaughtUpTimestamp = -1

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

High watermark is unknown when a new leader is elected 

• In such case, the empty set should be returned because we don't know the high watermark.
• Committed voters can be returned as non-empty when leader update the high watermark

...

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.

...

• .

Compatibility, Deprecation, and Migration Plan

...