m1a2st commented on code in PR #23318:
URL: https://github.com/apache/kafka/pull/23318#discussion_r4110596200
##########
core/src/main/scala/kafka/server/AbstractFetcherThread.scala:
##########
@@ -502,24 +433,20 @@ abstract class AbstractFetcherThread(name: String,
/**
* Returns initial partition fetch state based on current state and the
provided `initialFetchState`.
- * From IBP 2.7 onwards, we can rely on truncation based on diverging data
returned in fetch responses.
- * For older versions, we can skip the truncation step iff the leader epoch
matches the existing epoch.
+ * We rely on truncation based on diverging data returned in fetch responses.
*/
private def partitionFetchState(tp: TopicPartition, initialFetchState:
InitialFetchState, currentState: PartitionFetchState): PartitionFetchState = {
if (currentState != null && currentState.currentLeaderEpoch ==
initialFetchState.currentLeaderEpoch) {
currentState
} else if (initialFetchState.initOffset < 0) {
fetchOffsetAndTruncate(tp, initialFetchState.topicId,
initialFetchState.currentLeaderEpoch)
- } else if (leader.isTruncationOnFetchSupported) {
+ } else {
Review Comment:
Thanks for the explanation, that makes sense. Since `initOffset` is already
the HWM when there is no leader epoch, truncation becomes a no-op.
With this change, nothing transitions a replica into
`ReplicaState.TRUNCATING` anymore. If that sounds reasonable to you, I'll file
a follow-up Jira to remove `ReplicaState.TRUNCATING` and
`PartitionFetchState.isTruncating()`.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
