JingsongLi commented on code in PR #10431:
URL: https://github.com/apache/paimon/pull/10431#discussion_r4244881041
##########
paimon-python/pypaimon/write/commit/conflict_detection.py:
##########
@@ -282,6 +282,12 @@ def check_conflicts(
if conflict is not None:
return conflict
+ if (not delta_entries and self._row_id_check_from_snapshot is not None
+ and any(entry.index_file.global_index_meta is not None for
entry in (delta_index_entries or []))
+ and (latest_snapshot is None or latest_snapshot.id !=
self._row_id_check_from_snapshot)):
Review Comment:
[P1] Validate the captured snapshot identity before publishing maintenance
Snapshot IDs can be reused after public rollback, so comparing only the ID
does not enforce the new strict snapshot guard. I reproduced this with a
data-evolution table: append 0 (snapshot 1), append 10 (snapshot 2), start
BTree maintenance, and after its build completes call rollback_to(1) then
append 20. The replacement snapshot has ID 2 and the same schema/next_row_id,
but a different UUID and data. Maintenance accepts it and publishes its old
index for [0,10] as snapshot 3. A normal filter id=20 returns [{id:20}], while
the same filter with the published global index returns no rows.
Row-range validation accepts the reused row IDs, and commit CAS uses the
replacement snapshot's UUID read during publication, so neither protects the
original plan. Please carry the captured snapshot identity into the maintenance
commit and compare it on every publication attempt, using UUID or an equivalent
immutable identity in addition to ID. Add a rollback-and-reappend regression
that rejects this stale plan and preserves correct filtering.
--
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]
