The GitHub Actions job "CI" on fluss.git/dv-snapshot-scan-options has succeeded. Run started by GitHub user luoyuxia (triggered by luoyuxia).
Head commit for run: a7d7fdcb56399c5b5d07e5c4ce5fb4ea88269eae / luoyuxia <[email protected]> [lake] Fix premature snapshot deletion for DV readable offsets For Paimon DV tables, getReadableSnapshotAndOffsets returns an earliestSnapshotIdToKeep telling Fluss which lake snapshots may be deleted. When the latest compacted snapshot had no L0 in any bucket, the code shortcut earliestSnapshotIdToKeep to that compacted snapshot's previous APPEND, assuming nothing earlier was needed. This was unsound: a bucket can be clean (no L0) in the current compacted snapshot yet still be anchored to an older snapshot - it was flushed earlier and has not been flushed since, so its base anchor (the previous APPEND of the latest snapshot that exactly holds its most-recently flushed L0) can be older than the compacted snapshot's previous APPEND. Once such a bucket later receives new L0, recomputation traces back to that older anchor; if it was already deleted, the retrieval returns null and readable offsets can no longer advance. Fix by also computing the base anchor for buckets without L0 and lowering earliestSnapshotIdToKeep to the minimum anchor across all buckets. This is best-effort: if a bucket's flush history has expired and its anchor cannot be determined, keep all previous snapshots rather than risk deleting a needed one; it never blocks the readable-offset advance. The shared anchor computation is extracted into findBaseAnchorAppendSnapshot, reused by both the with-L0 offset traversal and the new no-L0 retention pass. The partitioned test expectation that encoded the old, over-aggressive value is updated accordingly. Co-Authored-By: Claude Opus 4.8 <[email protected]> Report URL: https://github.com/apache/fluss/actions/runs/28082510475 With regards, GitHub Actions via GitBox
