How does Kafka handle log truncation during replica recovery?

A follower that restarts, or becomes a follower after a leadership change, may hold log entries that the current leader does not have, for example entries that were never replicated to all in-sync replicas. It has to discard that divergent suffix before it fetches. Originally followers truncated to their last known high watermark, but that could lose committed data or leave the logs diverged (KIP-101). Modern Kafka uses leader epochs instead: the follower sends an OffsetsForLeaderEpoch request with its latest leader epoch, the leader replies with the end offset of that epoch (or of the largest epoch not greater than the requested one, per KIP-279), and the follower truncates its log to that offset and then fetches from the leader to catch up. Fetch responses can also report a diverging epoch so the follower truncates without a separate request. Only if epoch information is unavailable does it fall back to truncating to the high watermark. Afterwards the follower's log is identical to the leader's up to the offsets they share, so all in-sync replicas hold the same committed log.

Expected key concepts: truncate, leader epoch, OffsetsForLeaderEpoch, high watermark, follower, leader, diverge, fetch, KIP-101, in-sync replicas