[Bug] Snapshot live manifest entry cache serves stale entries after a rollback #298

Search before asking

• I searched in the issues and found nothing similar.

Paimon-cpp version

main (ded7cfb)

Minimal reproduce step

1. Primary key table with one bucket, three commits (snapshots 1 to 3): (k1, v1), (k2, v2), then (k3, v3), then (k1, v1b).

2. Scan it with a Cache on the ScanContext and scan.manifest-entry-cache.max-snapshots = 2; the live manifest entries of snapshot 3 are now cached for bucket 0.

3. Roll back and commit twice more, for example from Flink:

   CALL sys.rollback_to(`table` => 'default.t', snapshot_id => 1);
   INSERT INTO t VALUES ('k4', 'v4');
   INSERT INTO t VALUES ('k1', 'v1c');

   The rollback deletes snapshot-2, snapshot-3 and the data files only they referenced; the inserts create a new snapshot-2 and snapshot-3.

4. Scan again through the same Cache.

What doesn't meet your expectations?

The second scan plans from the cached entries of the deleted snapshot 3: reading k1 or k3 fails with Not exist: File .../bucket-0/data-....parquet not exists, k4 returns no row although it was committed, only k2 is correct. It recovers once a fourth snapshot moves the ids past the cached ones.

FileStoreScan::ReadManifestEntriesWithCache treats cached->snapshot_id == snapshot.Id() as a hit (file_store_scan.cpp:343); nothing else identifies the snapshot, so an id reused after a rollback (or after dropping and recreating a table at the same path) matches entries of a different snapshot. The cache is off by default (max-snapshots = 0); a long-lived process that enables it for point lookups is exposed.

Anything else?

Storing the snapshot's delta manifest list name with the cached entries and requiring it to match on a hit is enough: the name carries a UUID, so a rewritten snapshot never matches and falls through to the existing rebuild.

Are you willing to submit a PR?

• I'm willing to submit a PR!