[
https://issues.apache.org/jira/browse/KAFKA-20740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
José Armando García Sancio updated KAFKA-20740:
-----------------------------------------------
Summary: It is possible to have more than one concurrent voter change
operation (was: It is possible to have more hand one concurrent voter change
operation)
> It is possible to have more than one concurrent voter change operation
> ----------------------------------------------------------------------
>
> Key: KAFKA-20740
> URL: https://issues.apache.org/jira/browse/KAFKA-20740
> Project: Kafka
> Issue Type: Bug
> Components: kraft
> Affects Versions: 4.0.0
> Reporter: José Armando García Sancio
> Assignee: Jonah Hooper
> Priority: Major
>
> KRaft maintains an invariant where only a single voter change operation can
> be pending at any given time. This operation is restricted to a single
> modification—one addition, removal, or update—relative to the committed voter
> set. This constraint is essential to prevent split-brain scenarios or
> inconsistencies, ensuring that a majority of voters in both the old and new
> configurations have committed to and agree upon the change.
> Currently, KRaft violates this invariant by relying on the change voter
> handler state to enforce the single-pending-operation rule. A problem arises
> when an operation times out while the KRaft control records are still
> residing in the log or batch accumulator; in these instances, KRaft may
> incorrectly reset the change voter handler state.
> To resolve this, the code must be modified so that the change voter handler
> state is not reset once KRaft control records have been dispatched to the
> batch accumulator. Following that dispatch, the state should only be reset
> through replication, specifically via High Watermark (HWM) advancement.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
