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.

This mechanism strengthens the Raft membership model by:

Only committed voters are guaranteed to participate in quorum decisions and maintain data durability.Observability, automation, and monitoring systems should evaluate quorum health and tolerance based solely on the committed voter set, not on nodes that are still joining or pending commitment. This ensures that safety decisions—such as whether a quorum is available—remain consistent with Raft guarantees.
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 replicas 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
Making committed membership explicit.
Providing a consistent interface for tooling.
Improving the overall transparency and debuggability of the cluster state.

Public Interfaces

...

Space shortcuts