lianetm commented on code in PR #16673:
URL: https://github.com/apache/kafka/pull/16673#discussion_r1697100482
##########
clients/src/main/java/org/apache/kafka/clients/consumer/internals/AsyncKafkaConsumer.java:
##########
@@ -1443,12 +1443,7 @@ public void assign(Collection<TopicPartition>
partitions) {
// be no following rebalance.
//
// See the ApplicationEventProcessor.process() method that handles
this event for more detail.
- applicationEventHandler.add(new
AssignmentChangeEvent(subscriptions.allConsumed(), time.milliseconds()));
-
- log.info("Assigned to partition(s): {}",
partitions.stream().map(TopicPartition::toString).collect(Collectors.joining(",
")));
-
- if (subscriptions.assignFromUser(new HashSet<>(partitions)))
- applicationEventHandler.add(new
NewTopicsMetadataUpdateRequestEvent());
+ applicationEventHandler.add(new
AssignmentChangeEvent(time.milliseconds(), partitions));
Review Comment:
Adding this only means that we will potentially return from the `assign()`
without having really updated the subscription state. I wonder if we should go
with the same approach we have on the unsubscribe
[here](https://github.com/apache/kafka/blob/901c656a1da16c8473200c93e57991004fc1371d/clients/src/main/java/org/apache/kafka/clients/consumer/internals/AsyncKafkaConsumer.java#L1487-L1492),
that needs to deal with a very similar situation (and actually, assign with
empty triggers unsubscribe and goes down that path that seems more in-line with
what the legacy does).
The trick would be to add the assign event, but then poll for background
events until the assign event completes (so we know that the subscription state
was updated). Makes sense?
--
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
