...

On the level of a single partition, a relaxed offset commit check can be defined using an assignment epoch for each assigned partition and each member, which is the epoch at which the partition was assigned to that member. To fence against zombie commit requests, we can reject all offset commit requests from a member that who either does not have the partition assigned or that includes any member epoch that is smaller or equal to than the assignment epoch for that member and that partition.

...

When a static member leaves the group, the assignment epochs will be removed from set to 0 in the current assignment record. The record is then handled like a legacy record above; the assignment epoch will be initialized on load to the current member epoch, which will be -2 in this case. Partitions When the static member rejoins, partitions will therefore be considered to be assigned "from the beginning" (i.e., from epoch 0) to the new member ID. All commits using the old memberId will be fenced, and all commits using the new memberId will be permitted (since all client-side member epochs are larger than -2), and all commits using the new memberId will be permitted0).

Public Interfaces

ConsumerGroupCurrentMemberAssignmentValue

We add a new field, AssignmentEpochs to TopicPartitions. To keep the representation compact, we store it as an array aligned with Partitions, that is, for every item in partition there is one item in AssignmentEpochs. The field is nullable and tagged. For legacy records that do not include the assignment epochs, it will be be null, and assignment epochs for all partitions in assignedPartitions and partitionsPendingRevocation are considered to be equal to memberEpoch.

...