smjn commented on code in PR #19026:
URL: https://github.com/apache/kafka/pull/19026#discussion_r1993855898
##########
core/src/test/scala/unit/kafka/server/ShareGroupHeartbeatRequestTest.scala:
##########
@@ -261,7 +273,7 @@ class ShareGroupHeartbeatRequestTest(cluster:
ClusterInstance) {
val topicPartitionsAssignedToMember2 =
shareGroupHeartbeatResponse.data.assignment.topicPartitions()
// Verify the response.
- assertEquals(3, shareGroupHeartbeatResponse.data.memberEpoch)
+ assertEquals(4, shareGroupHeartbeatResponse.data.memberEpoch)
Review Comment:
This is beacause the member 1 had caused the group epoch to advance to 4. At
that point the assignment for both members was calculated.
Now member 2 sends an epoch 2 in the request but no assignment calculation
needs be done. In the reconcile method, the member epoch is updated with the
targetAssignment epoch (this is existing code). So the member epoch 3 as
response never happens, however the quality of being monotonically increasing
is still maintained.
Furthermore, in this test, the topic is created after members send their
first hearbeat - so member 1s second hearbeat causes group subscription to
update properly and hence member 1 takes overall 4 hearbeats. But this also
advances the target assignment epoch, which is eventually returned for member 2
as well.
Had we created the topic before heartbeating - we would end up with 3 as the
epoch
@AndrewJSchofield
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
