lukestephenson-zendesk commented on code in PR #13447: URL: https://github.com/apache/kafka/pull/13447#discussion_r1235166042
########## clients/src/main/java/org/apache/kafka/clients/Metadata.java: ########## @@ -399,8 +399,13 @@ private Optional<MetadataResponse.PartitionMetadata> updateLatestMetadata( // Between the time that a topic is deleted and re-created, the client may lose track of the // corresponding topicId (i.e. `oldTopicId` will be null). In this case, when we discover the new // topicId, we allow the corresponding leader epoch to override the last seen value. - log.info("Resetting the last seen epoch of partition {} to {} since the associated topicId changed from {} to {}", - tp, newEpoch, oldTopicId, topicId); + if (oldTopicId != null) { + log.info("Resetting the last seen epoch of partition {} to {} since the associated topicId changed from {} to {}", + tp, newEpoch, oldTopicId, topicId); + } else { + log.debug("Resetting the last seen epoch of partition {} to {} since the associated topicId was undefined but is now set to {}", Review Comment: @jolshan Why did you end up discarding this change? I'm seeing lots of noise from my Kafka producers because this is still at info level. The next commit [Reorganize logic](https://github.com/apache/kafka/pull/13447/commits/8c7549cece628e12654cb636b31283a3ba2d45fe) which from the commit description I wasn't expecting any functional changes, but it got rid of this change to log levels. Was that intended? If this was logged at debug level, it would reduce a lot of noise for my producers. Thanks. -- 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