lianetm commented on code in PR #14357:
URL: https://github.com/apache/kafka/pull/14357#discussion_r1361436357
##########
clients/src/main/java/org/apache/kafka/clients/consumer/internals/MembershipManagerImpl.java:
##########
@@ -248,4 +261,28 @@ public void
updateAssignment(ConsumerGroupHeartbeatResponseData.Assignment assig
}
maybeTransitionToStable();
}
+
+ @Override
+ public void completeReconcile(Set<TopicPartition> revokedPartitions,
+ Set<TopicPartition> assignedPartitions,
+ Optional<KafkaException> callbackError) {
+ if (callbackError.isPresent()) {
+ // TODO: how to react to callback errors?
+ }
+
+ assignmentReconciler.completeReconcile(revokedPartitions,
assignedPartitions);
+ transitionTo(MemberState.STABLE);
+ // TODO: update state to signal the HeartbeatRequestManager to send an
ACK heartbeat
+ }
+
+ @Override
+ public void completeLost(Set<TopicPartition> lostPartitions,
Optional<KafkaException> callbackError) {
+ if (callbackError.isPresent()) {
+ // TODO: how to react to callback errors?
+ }
+
+ assignmentReconciler.completeLost(lostPartitions);
+ transitionTo(MemberState.UNJOINED);
Review Comment:
UNJOINED here seems not right, given that I see a difference between being
FENCED (existing member out of a group, should join with epoch 0, and its
current member ID) vs being UNJOINED (new member out of a group, should join
with epoch 0 but without any member ID). It relates to my previous
[comment](https://github.com/apache/kafka/pull/14357/files/a68a42d8548f0cbb53ac1bddaf013d8b7c190cb0..160462e8d515904fd0df9e8ffc42bdf56c8e5b76#r1361424454)
about transitions when fenced. Thoughts?
--
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
