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

Reply via email to