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

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.1.0, 2.2.0, 2.3.0, 2.4.0
• Fix Version/s: 2.5.0
• Component/s: core
• Assignee: Jason Gustafson
• Reporter: Lucas Bradstreet
• Created: 27/Dec/19 19:08
• Updated: 17/Jan/20 22:44
• Resolved: 17/Jan/20 22:44

Description

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.

Issue Links

• links to: GitHub Pull Request #7970