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