[jira] [Updated] (KAFKA-17030) Voters should not assume that the leader will send them BeginQuorumEpoch requests

["Colin McCabe (Jira)" <ji...@apache.org>]

     [ 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)