KAFKA-19233: Allow fenced members to rejoin consumer group with epoch 0 #21305
Conversation
This fix allows members to rejoin a consumer group with memberEpoch=0 after being fenced, as specified by KIP-848. Previously, the validation in throwIfConsumerGroupMemberEpochIsInvalid rejected epoch=0 when the member had a higher epoch on the server. Changes: - Add early return for receivedMemberEpoch=0 in validation method - Add unit tests for rejoin in STABLE, UNREVOKED_PARTITIONS, and UNRELEASED_PARTITIONS states - Add integration test for fenced member rejoin flow
squah-confluent
left a comment
squah-confluent
left a comment
There was a problem hiding this comment.
Thanks for the patch!
| // Prepare assignment for rejoin. | ||
| assignor.prepareGroupAssignment(new GroupAssignment( | ||
| Map.of(memberId, new MemberAssignmentImpl(mkAssignment( | ||
| mkTopicAssignment(fooTopicId, 0, 1, 2) | ||
| ))) | ||
| )); |
There was a problem hiding this comment.
I don't think this is used in any of the tests since the group epoch is not bumped?
lianetm
left a comment
lianetm
left a comment
There was a problem hiding this comment.
Thanks! Just minor comment on tests
| assignor.prepareGroupAssignment(new GroupAssignment( | ||
| Map.of(memberId, new MemberAssignmentImpl(mkAssignment( | ||
| mkTopicAssignment(fooTopicId, 0, 1, 2) | ||
| ))) | ||
| )); |
There was a problem hiding this comment.
is this really needed? I would expect that since nothing really changed on the GC side (we're just retrieving the state for a member that is coming back), we wouldn't need to ask the assignor to do anything. Am I missing something? (same on other tests here if this makes sense)
|
@lianetm @squah-confluent Addressed your comments. |
|
Do we have the same issue for streams group and share group? looks like they both have similar member epoch check |
Yes. I will opened separate PRs for those. |
mjsax
changed the title
4 participants
This fix allows members to rejoin a consumer group with memberEpoch=0
after being fenced, as specified by KIP-848. Previously, the validation
in throwIfConsumerGroupMemberEpochIsInvalid rejected epoch=0 when the
member had a higher epoch on the server.
Changes:
UNRELEASED_PARTITIONS states
Reviewers: Dongnuo Lyu dlyu@confluent.io, Sean Quah
squah@confluent.io, Lianet Magrans lmagrans@confluent.io