ijuma commented on code in PR #12734:
URL: https://github.com/apache/kafka/pull/12734#discussion_r995790517
##########
core/src/main/scala/kafka/cluster/Partition.scala:
##########
@@ -1339,6 +1341,26 @@ class Partition(val topicPartition: TopicPartition,
}
}
+ // Fetching from a follower is only allowed from version 11 of the fetch
request. Our intent
+ // was to allow it assuming that those would also implement KIP-320
(leader epoch). It turns
+ // out that some clients use version 11 without KIP-320 and the broker
allows this. The issue
+ // is that we don't know whether the client fetches from the follower
based on the order of
+ // the leader or by mistake e.g. based on stale metadata. The latter means
that a client could
+ // end up on the follower with a offset that the follower does not have
yet. Instead of returning
+ // OffsetOutOfRangeException, we return an empty batch to the client with
the expectation that
+ // the client will retry and eventually refresh its metadata. Note that we
only do this if the
+ // client does not provide a leader epoch and use version 11.
+ if (isFollower && !currentLeaderEpoch.isPresent && fetchOffset >
initialLogEndOffset) {
Review Comment:
Unclean leader election, fetch version > 11 and no KIP-320 implemented seems
like it would be rare enough not to make things too complex for it. KIP-320 is
being implemented for librdkafka as we speak and we should file an issue on
Sarama's and kafkajs's issue tracker for them to implement it too. That's the
only way to have truly sane behavior.
--
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
