Skip to content

[Bug] [Python] fast_forward keeps main's own newer snapshots #10887

Open

Description

@RyanLin5967

Search before asking

  • 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].

import pyarrow as pa
from pypaimon import CatalogFactory, Schema

cat = CatalogFactory.create({"warehouse": "wh"})
cat.create_database("db", True)
sch = pa.schema([("k", pa.int64())])
cat.create_table("db.t", Schema.from_pyarrow_schema(sch), False)


def write(name, k):
    wb = cat.get_table(name).new_batch_write_builder()
    w, c = wb.new_write(), wb.new_commit()
    w.write_arrow(pa.table({"k": [k]}, schema=sch))
    c.commit(w.prepare_commit())


def read(name):
    rb = cat.get_table(name).new_read_builder()
    return sorted(rb.new_read().to_arrow(rb.new_scan().plan().splits())["k"].to_pylist())


write("db.t", 1)
cat.get_table("db.t").create_tag("v1", 1)
cat.create_branch("db.t", "b", "v1")
write("db.t$branch_b", 2)
write("db.t", 3)
write("db.t", 4)
cat.fast_forward("db.t", "b")
print(read("db.t"))
# [1, 3, 4], should be [1, 2]
print(read("db.t$branch_b"))
# [1, 2]

What doesn't meet your expectations?

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.

Are you willing to submit a PR?

  • I'm willing to submit a PR!

Activity

  1. skyyyy955 commented on Nov 2, 2026

    @skyyyy955
    Contributor

    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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions