[
https://issues.apache.org/jira/browse/KAFKA-17030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colin McCabe updated KAFKA-17030:
---------------------------------
Parent: KAFKA-17241
Issue Type: Sub-task (was: Bug)
> 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: José Armando García Sancio
> Priority: Major
>
> 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)
