apache/iceberg · warning

Failed to load committed snapshot, skipping manifest clean-u

Error message

Failed to load committed snapshot, skipping manifest clean-up

What it means

This warning is emitted during SnapshotProducer.commit()'s cleanup phase when re-reading the table's latest metadata fails to find the just-committed snapshot. It typically indicates eventual-consistency problems in the underlying catalog refresh, so the newly written manifest lists cannot be confirmed as committed. Because commit state cannot be verified, the producer deliberately skips manifest clean-up to avoid deleting files that may belong to the committed snapshot.

Source

Thrown at core/src/main/java/org/apache/iceberg/SnapshotProducer.java:556

        // id in case another commit was added between this commit and the refresh.
        // it might not be known which commit attempt succeeded in some cases, so this only cleans
        // up the one that actually did succeed.
        Snapshot saved = ops.refresh().snapshot(newSnapshotId.get());
        if (saved != null) {
          if (cleanupAfterCommit()) {
            cleanUncommitted(Sets.newHashSet(saved.allManifests(ops.io())));
          }

          // also clean up unused manifest lists created by multiple attempts
          for (String manifestList : manifestLists) {
            if (!saved.manifestListLocation().equals(manifestList)) {
              deleteFile(manifestList);
            }
          }
        } else {
          // saved may not be present if the latest metadata couldn't be loaded due to eventual
          // consistency problems in refresh. in that case, don't clean up.
          LOG.warn("Failed to load committed snapshot, skipping manifest clean-up");
        }
      } catch (Throwable e) {
        LOG.warn(
            "Failed to load committed table metadata or during cleanup, skipping further cleanup",
            e);
      }
    }

    try {
      notifyListeners();
    } catch (Throwable e) {
      LOG.warn("Failed to notify event listeners", e);
    }
  }

  private void notifyListeners() {
    try {
      Object event = updateEvent();

View on GitHub (pinned to 86d9c8fc54)

Solutions

1. Verify the catalog/storage backend provides strong read-after-write consistency (or enable an Iceberg lock/catalog implementation that does).
2. Check for concurrent writers fighting over the same table and ensure a proper catalog locking mechanism is in place.
3. Retry the commit; the warning is non-fatal — orphan manifests can be removed later with ExpireSnapshots or removeOrphanFiles.
4. Inspect catalog logs to confirm whether the commit actually landed; if it did, no data loss occurred, only leftover files.

Example fix

// before
Table table = catalog.loadTable(identifier);
table.newAppend().appendFile(dataFile).commit(); // catalog refresh is eventually consistent
// after
Table table = catalog.loadTable(identifier);
table.refresh(); // ensure fresh metadata before committing
table.newAppend().appendFile(dataFile).commit();
// then run removeOrphanFiles/expireSnapshots periodically to clean leftovers

if (!table.operations().current().snapshot(table.currentSnapshot().snapshotId()).isPresent()) {
  throw new IllegalStateException("Catalog refresh did not return the committed snapshot; skipping dependent cleanup");
}

When it happens

Trigger: table.refresh() or the catalog read inside commit cleanup returns metadata that does not contain the committed snapshot, usually because the catalog store exhibits read-after-write (eventual) consistency lag during a commit via SnapshotProducer.commit().

Common situations: Committing to tables in eventually-consistent object stores (e.g. S3 without strong consistency guarantees) or catalogs with replication lag; concurrent commits from other jobs racing with cleanup; network blips during metadata re-read.

Related errors

• Table does not exist: %s
• View does not exist: %s
• An error occurred closing catalog instance, ignoring...
• Failed to load committed metadata, skipping clean-up
• Failed to load committed table metadata or during cleanup, s

AI-assisted analysis of apache/iceberg@86d9c8fc54 (2026-09-12). Data as JSON: /api/errors/d2980763cd60d2c4. Report an issue: GitHub.