[jira] [Created] (KAFKA-9338) Incremental fetch sessions do not maintain or use leader epoch for fencing purposes

["Lucas Bradstreet (Jira)" <ji...@apache.org>]

Lucas Bradstreet created KAFKA-9338:
---------------------------------------

             Summary: Incremental fetch sessions do not maintain or use leader epoch for fencing purposes
                 Key: KAFKA-9338
                 URL: https://issues.apache.org/jira/browse/KAFKA-9338
             Project: Kafka
          Issue Type: Bug
          Components: core
    Affects Versions: 2.4.0, 2.3.0, 2.2.0, 2.1.0
            Reporter: Lucas Bradstreet


KIP-320 adds the ability to fence replicas by detecting stale leader epochs from followers, and helping consumers handle unclean truncation.

Unfortunately the incremental fetch session handling does not maintain or use the leader epoch in the fetch session cache. As a result, it does not appear that the leader epoch is used for fencing a majority of the time. I'm not sure if this is only the case after incremental fetch sessions are established - it may be the case that the first "full" fetch session is safe.

Optional.empty is returned for the FetchRequest.PartitionData here:

[https://github.com/apache/kafka/blob/a4cbdc6a7b3140ccbcd0e2339e28c048b434974e/core/src/main/scala/kafka/server/FetchSession.scala#L111]

I believe this affects brokers from 2.1.0 when fencing was improved on the replica fetcher side, and 2.3.0 and above for consumers, which is when client side truncation detection was added on the consumer side.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)