ShivsundarR commented on code in PR #19192:
URL: https://github.com/apache/kafka/pull/19192#discussion_r1991728528


##########
clients/src/main/java/org/apache/kafka/clients/consumer/internals/ShareConsumeRequestManager.java:
##########
@@ -1004,8 +1014,10 @@ private void 
updateLeaderInfoMap(ShareAcknowledgeResponseData.PartitionData part
     }
 
     private TopicIdPartition lookupTopicId(Uuid topicId, int partitionIndex) {
-        String topicName = metadata.topicNames().getOrDefault(topicId,
-                topicNamesMap.remove(new IdAndPartition(topicId, 
partitionIndex)));
+        String topicName = metadata.topicNames().get(topicId);
+        if (topicName == null) {
+            topicName = topicNamesMap.remove(new IdAndPartition(topicId, 
partitionIndex));
+        }

Review Comment:
   I was observing a weird behaviour where even if `metadata.topicNames()` had 
a key-value pair, calling 
   ```
   metadata.topicNames().getOrDefault(topicId,
                   topicNamesMap.remove(new IdAndPartition(topicId, 
partitionIndex))
   ```
   would result in the execution of "`topicNamesMap.remove(new 
IdAndPartition(topicId, partitionIndex)`".
   If we had topic names in the metadata and still removed the topicId from the 
`topicNamesMap`, then when the subscription changed, we would not see the topic 
name as everytime we would pop the topic name from the map during 
`handleShareFetch` itself.
   I have temporarily changed the usage here to have 2 explicit checks. But 
still not clear why the `getOrDefault` did not work.



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