[
https://issues.apache.org/jira/browse/KAFKA-19522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18008279#comment-18008279
]
Calvin Liu commented on KAFKA-19522:
------------------------------------
[~mimaison] Thanks for checking. I think the effect is minor. However, if 4.1
is still open, we can include it in 4.1. The review should be straightforward,
and I can have it merged shortly.
> LastKnownLeader should only be elected if it is unfenced
> --------------------------------------------------------
>
> Key: KAFKA-19522
> URL: https://issues.apache.org/jira/browse/KAFKA-19522
> Project: Kafka
> Issue Type: Bug
> Affects Versions: 4.1.0
> Reporter: Calvin Liu
> Assignee: Calvin Liu
> Priority: Major
> Fix For: 4.1.0
>
>
> In PartitionChangeBuilder, there is a bug that even if the laterKnownLeader
> is fenced, it can still be a leader.
> The effect could be minor. Here is a real case:
> When all the replicas(0, 1, 2) are down, the ELR set could be (1, 2) and the
> last known leader is (2). The leader is -1.
> Then if 0 and 1 come up uncleanly the ELR field will be (2). This partition
> can't elect 2 as the leader, because ELR is not empty.
> Then when 2 comes up, it comes up cleanly, then we are happy to have it as
> the new leader cleanly(through ELR election). However, if it comes up
> uncleanly, it will be elected as the leader uncleanly. Though it is expected,
> notice that, replica 2 is still fenced until the next heartbeat. So
> effectively, broker 2 is just elected as the leader a little bit ahead of
> time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
