apache/iceberg · error · NoSuchViewException

Cannot rename %s to %s. View does not exist

Error message

Cannot rename %s to %s. View does not exist

What it means

NoSuchViewException from InMemoryCatalog.renameView: the destination namespace exists (checked just before), but the source view identified by 'from' has no entry in the catalog, so there is nothing to rename. The message names both the source and destination identifiers.

Source

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

      return null != views.remove(identifier);
    }
  }

  @Override
  public void renameView(TableIdentifier from, TableIdentifier to) {
    if (from.equals(to)) {
      return;
    }

    synchronized (this) {
      if (!namespaceExists(to.namespace())) {
        throw new NoSuchNamespaceException(
            "Cannot rename %s to %s. Namespace does not exist: %s", from, to, to.namespace());
      }

      String fromViewLocation = views.get(from);
      if (null == fromViewLocation) {
        throw new NoSuchViewException("Cannot rename %s to %s. View does not exist", from, to);
      }

      if (tables.containsKey(to)) {
        throw new AlreadyExistsException("Cannot rename %s to %s. Table already exists", from, to);
      }

      if (views.containsKey(to)) {
        throw new AlreadyExistsException("Cannot rename %s to %s. View already exists", from, to);
      }

      views.put(to, fromViewLocation);
      views.remove(from);
    }
  }

  @Override
  protected Map<String, String> properties() {
    return catalogProperties == null ? ImmutableMap.of() : catalogProperties;

View on GitHub (pinned to 86d9c8fc54)

Solutions

  1. Verify the source exists via listViews(from.namespace()) or a preceding drop/rename success
  2. Fix the source TableIdentifier spelling
  3. Handle races by catching NoSuchViewException and treating idempotent rename as done

Example fix

// before
catalog.renameView(from, to);
// after
if (catalog.listViews(from.namespace()).contains(from)) {
  catalog.renameView(from, to);
}
Defensive patterns

Strategy: validation

Validate before calling

if (!catalog.listViews(from.namespace()).contains(from)) throw new IllegalStateException("View missing: " + from);

Try / catch

try { catalog.renameView(from, to); } catch (NoSuchViewException e) { /* view already moved or dropped; treat as idempotent */ }

Prevention

When it happens

Trigger: Calling catalog.renameView(from, to) where views.get(from) is null — the view was already dropped/renamed or never created.

Common situations: Double-rename in retry logic; typos in the source view name; renaming a table as if it were a view (tables live in a separate map).

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/0577ac152157c982. Report an issue: GitHub.