[
https://issues.apache.org/jira/browse/KAFKA-17030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
José Armando García Sancio updated KAFKA-17030:
-----------------------------------------------
Fix Version/s: 3.9.1
> Voters should not assume that the leader will send them BeginQuorumEpoch
> requests
> ---------------------------------------------------------------------------------
>
> Key: KAFKA-17030
> URL: https://issues.apache.org/jira/browse/KAFKA-17030
> Project: Kafka
> Issue Type: Sub-task
> Reporter: José Armando García Sancio
> Assignee: Alyssa Huang
> Priority: Major
> Fix For: 3.9.1
>
>
> This issues depends on implementing
> https://issues.apache.org/jira/browse/KAFKA-16164
> Because of reconfiguration it is possible for a local replica to think that
> they are a voter but the KRaft leader doesn't have them in the voter set.
> Think a voter removal that committed before it was replicated to the removed
> voter.
> To address this issue KIP-853 suggest using Pre-Vote to fence the local
> replica from increasing their epoch. But in this state the local replica will
> be stuck because it will never discover the new leader. To fix this, voters
> must send Fetch requests to the bootstrap server and or the known leader
> while in the prospective state. This is similar to how observer discover the
> leader in the unattached and follower state.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
