[Bug] A filesystem commit can publish its snapshot after the lock lease expired #10953

Search before asking

• I searched in the issues and found nothing similar.

Paimon version

master (bf6c81c)

Compute Engine

JavaAPI

Minimal reproduce step

A filesystem-managed table on an object store whose rename is not atomic, committed by several writers with a lease-based catalog lock (for example JDBC or Hive with lock.enabled = true), as the concurrency control docs recommend. A commit's request that checks whether the new snapshot file already exists takes longer than the lease.

RenamingSnapshotCommitTest#testCommitRechecksLeaseAfterCheckingSnapshot in the linked PR reproduces it with a lock whose lease expires inside that existence check.

What doesn't meet your expectations?

The commit still publishes the snapshot after its lease has expired, when another writer may already hold the lock.

SnapshotCommit.commit checks the lease (Lock.ensureValid()) before it calls RenamingSnapshotCommit.commitImpl. commitImpl then calls fileIO.exists(newSnapshotPath) and, if the file is absent, tryToWriteAtomic, with no check in between. The existence check is a remote request on object stores, so it can outlast the lease.

Anything else?

#10845 found the same gap in fast_forward (a lease check followed by an existence check and then the write).

Are you willing to submit a PR?

• I'm willing to submit a PR!