nicktelford opened a new pull request, #22491: URL: https://github.com/apache/kafka/pull/22491
## Summary `AbstractSegments.committedOffset()` iterates the segment `TreeMap` in ascending key order (oldest segment first) and returns the first non-null offset it finds. Because inactive segments (past their time window) stop receiving data writes, their 16MB data CF write buffer never fills and never triggers an atomic flush. Their offset CF is updated by every 30-second `maybeCheckpoint()` call, but those writes sit in the memtable and are lost on an unclean JVM exit. The SST for an inactive segment therefore holds the offset from its last data-driven flush, which can be many hours old. When restoration reads the committed offset on restart, the current code returns the stale offset from the oldest segment rather than the current offset from the active (most recently flushed) segment. This stale offset may fall outside the changelog topic's retention window, causing `OffsetOutOfRangeException`. The fix iterates `segments.descendingMap().values()` so the newest segment — whose SST is kept current by active data writes and atomic flushes — is checked first. This is the same pattern already used in `allSegments(forward=false)`. ## Test plan - Existing `AbstractRocksDBSegmentedBytesStoreTest` / `RocksDBSegmentedBytesStoreTest` suites pass. - Add a test simulating stale SST on an older segment and asserting `committedOffset()` returns the newer segment's value. 🤖 Generated with [Claude Code](https://claude.ai/claude-code) -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
