Function fetch_visibility 

pub fn fetch_visibility(
    is_follower: bool,
    read_committed: bool,
    w: FetchWatermarks,
    fetch_offset: i64,
) -> FetchVisibility

Compute Kafka’s consumer/follower Fetch visibility window.

The reported watermarks are the partition’s own, for every fetcher: response_hw is the high watermark and response_lso is the last stable offset, capped at the high watermark as Kafka’s UnifiedLog.lastStableOffset caps it. Kafka’s Partition.readRecords reads both before the fetch and puts them in the LogReadInfo whatever the isolation level and whoever is fetching, so a follower learns the leader’s committed bound rather than its log end. That is what keeps a KIP-392 follower from exposing an offset the leader may still truncate.

FetchWatermarks::deliverable is KFC-1’s delivery watermark: the first offset a consumer may not see yet, because the batch that starts there has not reached its activation time. It caps a consumer, and it caps nothing else:

• A follower is never gated. Replication carries a scheduled record to the ISR, and it counts toward the high watermark, long before any consumer can read it.
• response_hw and response_lso do not move with it, so consumer lag stays honest and KIP-227 watermark monotonicity is untouched.

Offsets below the log start or above the log end are out of range. An offset equal to the log end remains a valid empty fetch.

There is no precondition. The consumer bound is proved outright: whatever the caller passes, a consumer never reads at or past the high watermark, the delivery watermark, or, under read_committed, the last stable offset.