lianetm commented on code in PR #20055:
URL: https://github.com/apache/kafka/pull/20055#discussion_r2185448060
##########
group-coordinator/src/main/java/org/apache/kafka/coordinator/group/GroupMetadataManager.java:
##########
@@ -2243,21 +2243,30 @@ private
CoordinatorResult<ConsumerGroupHeartbeatResponseData, CoordinatorRecord>
// epoch 0 and that it is fully initialized.
boolean bumpGroupEpoch = group.groupEpoch() == 0;
- bumpGroupEpoch |= hasMemberSubscriptionChanged(
+ boolean subscribedTopicNamesChanged = hasMemberSubscriptionChanged(
groupId,
member,
updatedMember,
records
);
-
- bumpGroupEpoch |= maybeUpdateRegularExpressions(
+ UpdateRegularExpressionsResult updateRegularExpressionsResult =
maybeUpdateRegularExpressions(
context,
group,
member,
updatedMember,
records
);
+ // The subscription has changed when either the subscribed topic names
or subscribed topic
+ // regex has changed.
+ boolean hasSubscriptionChanged = subscribedTopicNamesChanged ||
updateRegularExpressionsResult.subscribedTopicRegexChanged;
+ // Bumping the group epoch signals that the target assignment should
be updated. We bump the
+ // group epoch when the member has changed its subscribed topic names
or the member has
+ // changed its subscribed topic regex to a regex that is already
resolved. We explicitly
+ // avoid bumping the group epoch when the new subscribed topic regex
has not been resolved
Review Comment:
agree, but just to double check: given that we don't bump the epoch if the
client sends a new regex (unresolved),
- the target assignment for the client will remain unchanged (owning the
partitions that match the previous regex)
- but the coord won't re-send this "old" assignment?
--
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
