[GitHub] [kafka] hudeqi commented on a diff in pull request #13719: MINOR:Fix illogical log in fetchOffsetAndTruncate method

["hudeqi (via GitHub)" <gi...@apache.org>]

hudeqi commented on code in PR #13719:
URL: https://github.com/apache/kafka/pull/13719#discussion_r1195912888


##########
core/src/main/scala/kafka/server/AbstractFetcherThread.scala:
##########
@@ -680,12 +680,15 @@ abstract class AbstractFetcherThread(name: String,
        */
       val offsetAndEpoch = leader.fetchEarliestOffset(topicPartition, currentLeaderEpoch)
       val leaderStartOffset = offsetAndEpoch.offset
-      warn(s"Reset fetch offset for partition $topicPartition from $replicaEndOffset to current " +
-        s"leader's start offset $leaderStartOffset")
       val offsetToFetch = Math.max(leaderStartOffset, replicaEndOffset)
+      warn(s"Reset fetch offset for partition $topicPartition from $replicaEndOffset to " +

Review Comment:
   > Why do we have to log this at WARN level? Can we change it to the INFO level?
   
   Thanks for your review! Since the fetchOffsetAndTruncate method deals with the situation that a follower encounters an out of range during fetch, whether it is due to dirty elections that cause the log end offset of the old leader to be larger than the log end offset of the new leader requires truncate, or because the follower stopped for a long time causes the log end offset to be smaller than the leader's log start offset requires truncate, both of which belong to a type of "abnormal" processing case, so the logs in this method are all at the warn level. This is my understanding, please correct me if I am wrong, thank you! @kamalcph 



-- 
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-unsubscribe@kafka.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org