smjn commented on code in PR #19026:
URL: https://github.com/apache/kafka/pull/19026#discussion_r1993795193
##########
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:
No 4 is correct. In the new implementation, the groupEpoch is incremented
each time we receive a heartbeat and there are some initialized topics which
have not been assigned.
```
memberId: mPkH7gtLSki7J3yRAQviIA, req: 1, resp: 2, assign: null
memberId: mPkH7gtLSki7J3yRAQviIA, req: 2, resp: 3, assign: null
memberId: mPkH7gtLSki7J3yRAQviIA, req: 3, resp: 4, assign:
Assignment(topicPartitions=[TopicPartitions(topicId=1DIJ3JKHTU2pmPXmOR07tw,
partitions=[2])])
```
- This results in the first heartbeat after topic creation (as mentioned
above) have no subscription metadata attached and no work gets done.
- In the second heartbeat subscription is attached to group and a persister
request gets created and then share coord initialization
- In the third heartbeat, we can actually reconcile the assignment.
If we create the topic before doing any heartbeats, that would have 3 as
final 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
