[
https://issues.apache.org/jira/browse/KAFKA-20694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Schofield resolved KAFKA-20694.
--------------------------------------
Resolution: Fixed
> Fix share coordinator readState leaderEpoch -1 sentinel fencing
> ---------------------------------------------------------------
>
> Key: KAFKA-20694
> URL: https://issues.apache.org/jira/browse/KAFKA-20694
> Project: Kafka
> Issue Type: Bug
> Components: core
> Affects Versions: 4.2.1
> Reporter: Shekhar Prasad Rajak
> Assignee: Shekhar Prasad Rajak
> Priority: Major
> Fix For: 4.4.0, 4.3.2
>
>
> ShareCoordinatorShard.readStateAndMaybeUpdateLeaderEpoch treats leaderEpoch
> == -1 as a sentinel meaning “do not update leader epoch”, but
> maybeGetReadStateError fences the request before
> that logic runs when the stored leader epoch is greater than -1. This
> causes valid no-update readState requests to return FENCED_LEADER_EPOCH.
> *Expected behavior:*
> When ReadShareGroupStateRequest has leaderEpoch == -1, share coordinator
> should not update the stored leader epoch and should not apply stale-leader
> fencing. The response should succeed
> with Errors.NONE and produce no coordinator record.
> *Wrong scenario:*
> Stored leader epoch for share partition is 2.
> A readState request arrives with leaderEpoch=-1.
> Current code compares 2 > -1 and returns FENCED_LEADER_EPOCH.
> Expected: success response, no generated record, stored leader epoch
> remains 2.
> *Test gap:*
> testReadStateLeaderEpochUpdateNoUpdate only checks that no records are
> generated. A fenced response also generates no records, so the test passes
> incorrectly. Add assertion that the
> response partition error code is Errors.NONE.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
