Hi everyone, I’m trying to get a better understanding of how commit handling works in the Iceberg v2 context. Imagine I’m using the Java Iceberg implementation to write metadata files (such as manifests, manifest lists, and metadata JSON) and then commit them to the underlying catalog. Now, if I invoke the corresponding API from a database engine and an abort occurs-for example, a user‑triggered abort-the situation becomes complicated. Unless the metadata write API explicitly returns a commit success or commit conflict message, the database has no clear way of knowing whether the catalog was updated.
Even in cases where the catalog hasn’t yet been updated, there can be timing windows where the database tries to undo the write as part of processing the abort, but meanwhile the catalog may already have been updated with the latest metadata JSON. This lack of synchronization makes handling aborts tricky. I'm not aware if Iceberg provides any mechanisms similar to two‑phase commit. So, does this essentially mean that once the API is invoked, the only safe approach is to roll forward rather than attempt to roll back? Thanks, RKN
