Shekhar Prasad Rajak created KAFKA-20694:
--------------------------------------------
Summary: 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
Fix For: 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)
