Fix false transaction conflicts on commit retry

[fuziontech]

Summary

• Root cause: GetTransactionChanges() is computed once before the retry loop in FlushChanges(), but CommitChanges (via GetNewTableInfo) and WriteSnapshotChanges (via AddTableChanges) mutate it in-place by adding committed (remapped) table IDs. When the first commit attempt fails (duplicate snapshot_id race), these stale committed IDs persist into the retry.

• False conflict mechanism: On retry, CheckForConflicts compares the stale IDs against the other transaction's committed changes. Both transactions derived their committed IDs from the same next_catalog_id counter, so the IDs collide — producing a false conflict like "insert into table while another transaction altered it" even when operating on entirely different tables.

• Example scenario:

  • Tx A & Tx B both start from snapshot with next_catalog_id=25770
  • Tx A (first attempt): assigns committed table ID 25771 → WriteSnapshotChanges mutates tables_inserted_into += {25771} → Commit fails (Tx B committed first)
  • Tx B committed with altered_tables: {25771} (from COMMENT ON TABLE)
  • Tx A (retry): CheckForConflicts sees tables_inserted_into: {25771} (stale) vs altered_tables: {25771} (Tx B) → false conflict

• Fix: Move GetTransactionChanges() inside the retry loop so it is recomputed fresh each iteration

Test plan

• Added transaction_retry_stale_changes.test covering:
  • Concurrent INSERT + ALTER on different tables (both orderings)
  • Concurrent INSERT + COMMENT ON on different tables
  • All scenarios verify data correctness after both commits succeed

🤖 Generated with Claude Code