smjn opened a new pull request, #19363:
URL: https://github.com/apache/kafka/pull/19363

   * Currently, the delete share group code flow uses 
`group.subscribedTopicNames()` to fetch information about all the share 
partitions to which a share group is subscribed to.
   * However, this is incorrect since once the group is EMPTY, a precondition 
for delete, the aforementioned method will return an empty list.
   * In this PR we have leveraged the `ShareGroupStatePartitionMetadata` record 
to grab the `initialized` and `initializing` partitions to build the delete 
candidates, which remedies the situation.
   * The entire flow for delete share groups is now:
   ```
   GroupCoordinatorService.deleteGroups -> 
GroupCoordinatorService.deleteShareGroups -> 
GroupCoordinatorShard.sharePartitionDeleteRequests -> 
GroupMetadataManager.shareGroupBuildPartitionDeleteRequest (attaches 
deletingTopics to metadata) -> 
GroupCoordinatorService.performShareGroupsDeletion (makes persister delete 
request) -> GroupCoordinatorService.handleDeleteGroups (general delete flow) -> 
ShareGroup.createGroupTombstoneRecords (attaches metadata tombstone, groupEpoch 
tombstone)
   ```


-- 
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

Reply via email to