What causes "Table does not exist: %s" in apache/iceberg?

Re-check table existence before final commits in long-running jobs.

apache/iceberg · error · NoSuchTableException

Table does not exist: %s

Error message

Table does not exist: %s

What it means

Inside the tables.compute lambda of doCommit, if the map no longer contains an entry (existingLocation == null) while committing against a non-null base, the table was dropped concurrently. InMemoryCatalog throws NoSuchTableException because a metadata-location commit against a deleted table is meaningless.

Source

Thrown at core/src/main/java/org/apache/iceberg/inmemory/InMemoryCatalog.java:451

              "Cannot create table %s. Namespace does not exist: %s",
              tableIdentifier, tableIdentifier.namespace());
        }

        if (views.containsKey(tableIdentifier)) {
          throw new AlreadyExistsException(
              "View with same name already exists: %s", tableIdentifier);
        }

        tables.compute(
            tableIdentifier,
            (k, existingLocation) -> {
              if (!Objects.equal(existingLocation, oldLocation)) {
                if (null == base) {
                  throw new AlreadyExistsException("Table already exists: %s", tableName());
                }

                if (null == existingLocation) {
                  throw new NoSuchTableException("Table does not exist: %s", tableName());
                }

                throw new CommitFailedException(
                    "Cannot commit to table %s metadata location from %s to %s "
                        + "because it has been concurrently modified to %s",
                    tableIdentifier, oldLocation, newLocation, existingLocation);
              }
              return newLocation;
            });
      }
    }

    @Override
    public FileIO io() {
      return fileIO;
    }

    @Override

View on GitHub (pinned to 86d9c8fc54)

Solutions

Re-check table existence before final commits in long-running jobs.
Catch NoSuchTableException and abort/redirect the write if the drop was intentional.
Coordinate drop and write phases so commits are drained before dropping.

Example fix

// before
table.refresh();
table.commit(applyUpdate);

// after
if (catalog.tableExists(ident)) {
  table.refresh();
  table.commit(applyUpdate);
} else {
  // handle dropped table
}

Defensive patterns

Strategy: try-catch

Validate before calling

if (!catalog.tableExists(ident)) { throw new IllegalStateException("Table was dropped: " + ident); }

Try / catch

try { table.commit(update); } catch (NoSuchTableException e) { // abort pipeline or recreate table; do not retry blindly }

Prevention

Drain in-flight commits before dropTable in cleanup jobs
Re-check existence before committing after long computations
Avoid sharing Table handles across drop/recreate cycles

When it happens

Trigger: A commit initiated by catalog.loadTable(...).commit() (or fastAppend etc.) while another thread/client calls catalog.dropTable(ident) before the commit's compute step runs.

Common situations: Drop-and-recreate pipelines racing with running writers; cleanup jobs deleting idle tables that still have in-flight commits; test teardown interleaving with commit assertions.

Understand the failure class

Background: "Not found" and "does not exist" errors: why "Task not found", "No such folder", and "Can't find" fire when a lookup comes back empty — this error's family across 14 libraries.

Related errors

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