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
