Hangleton commented on code in PR #13378: URL: https://github.com/apache/kafka/pull/13378#discussion_r1133737665
########## core/src/main/scala/kafka/coordinator/group/GroupMetadataManager.scala: ########## @@ -469,11 +469,11 @@ class GroupMetadataManager(brokerId: Int, if (isTxnOffsetCommit) { group.inLock { addProducerGroup(producerId, group.groupId) - group.prepareTxnOffsetCommit(producerId, offsetMetadata) + group.prepareTxnOffsetCommit(producerId, offsetMetadata.map { case(k, v) => k.topicPartition -> v }) } } else { group.inLock { - group.prepareOffsetCommit(offsetMetadata) + group.prepareOffsetCommit(offsetMetadata.map { case(k, v) => k.topicPartition -> v }) Review Comment: Sure - I pushed a new commit [b6d9d2b](https://github.com/apache/kafka/pull/13378/commits/b6d9d2ba247a7880002486b23bd86db63c03212e) which propagates `TopicIdPartition` to the following `GroupMetadata` methods: ``` onOffsetCommitAppend prepareOffsetCommit failPendingOffsetWrite ``` and: ``` onTxnOffsetCommitAppend prepareTxnOffsetCommit failPendingTxnOffsetCommit ``` Please note that not all public methods of `GroupMetadata` use `TopicIdPartition`, and some of them remain `TopicPartition`-based. Do you think it is fine? (since `GroupMetadata` is an internal class, it should be I suppose). -- 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