You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug] [Python] fast_forward keeps main's own newer snapshots #10887
I searched in the issues and found nothing similar.
Paimon version
pypaimon 2.1.0. fast_forward is unchanged on master.
Compute Engine
Python API (pypaimon 2.1.0, Python 3.12.16, pyarrow 19.0.1) on a local filesystem catalog. Spark 3.5.6 with paimon-spark-3.5_2.12 2.1.0 for the comparison.
Minimal reproduce step
Currently, pypaimon's fast_forward copies the branch's snapshot files into main without first deleting main's snapshots from the branch point on, so once main has more snapshots than the branch, main keeps reading its own. Spark's CALL sys.fast_forward on the same table gives [1, 2].
After fast_forward("db.t", "b") main holds the branch's state and reads [1, 2].
Anything else?
If the branch has added a column, reading main after fast_forward raises AttributeError: 'NoneType' object has no attribute 'fields', since the branch's schema files are not copied either.
I reproduced both cases from Ryan's example on b434233 with the Python backend (Windows, Python 3.10, PyArrow 19.0.1, local filesystem): main still reads [1, 3, 4] after fast_forward returns, and adding a column on the branch leaves main without the referenced schema. The control without extra main commits or schema changes reads [1, 2].
#10880 has since merged, but fast_forward itself is unchanged at 30d9127. I'd like to work on this in the filesystem branch manager, with public-API regression tests. Given the related work in #10845, I'd like to confirm the metadata replacement and failure/retry behavior before implementing the fix.
Is anyone already working on this? If not, could you assign it to me?
Activity
skyyyy955 commentedon Nov 2, 2026
I reproduced both cases from Ryan's example on b434233 with the Python backend (Windows, Python 3.10, PyArrow 19.0.1, local filesystem): main still reads [1, 3, 4] after fast_forward returns, and adding a column on the branch leaves main without the referenced schema. The control without extra main commits or schema changes reads [1, 2].
#10880 has since merged, but fast_forward itself is unchanged at 30d9127. I'd like to work on this in the filesystem branch manager, with public-API regression tests. Given the related work in #10845, I'd like to confirm the metadata replacement and failure/retry behavior before implementing the fix.
Is anyone already working on this? If not, could you assign it to me?