What causes "Interrupted in call to dropTable" in apache/iceberg?

Verify the table's actual state afterwards — the drop may or may not have completed at the metastore.

apache/iceberg · error · RuntimeException

Interrupted in call to dropTable

Error message

Interrupted in call to dropTable

What it means

dropTable() catches InterruptedException, re-interrupts the thread, and rethrows a RuntimeException with this message. It means the thread was interrupted while the metastore drop RPC was in progress, so the table's drop outcome is unknown.

Source

Thrown at hive-metastore/src/main/java/org/apache/iceberg/hive/HiveCatalog.java:290

          });

      if (purge && lastMetadata != null) {
        CatalogUtil.dropTableData(ops.io(), lastMetadata);
      }

      LOG.info("Dropped table: {}", identifier);
      return true;

    } catch (NoSuchTableException | NoSuchObjectException e) {
      LOG.info("Skipping drop, table does not exist: {}", identifier, e);
      return false;

    } catch (TException e) {
      throw new RuntimeException("Failed to drop " + identifier, e);

    } catch (InterruptedException e) {
      Thread.currentThread().interrupt();
      throw new RuntimeException("Interrupted in call to dropTable", e);
    }
  }

  @Override
  public boolean dropView(TableIdentifier identifier) {
    if (!isValidIdentifier(identifier)) {
      return false;
    }

    try {
      String database = identifier.namespace().level(0);
      String viewName = identifier.name();

      HiveViewOperations ops = (HiveViewOperations) newViewOps(identifier);
      ViewMetadata lastViewMetadata = null;
      try {
        lastViewMetadata = ops.current();
      } catch (NotFoundException e) {

View on GitHub (pinned to 86d9c8fc54)

Solutions

Verify the table's actual state afterwards — the drop may or may not have completed at the metastore.
Let the interrupt propagate; do not swallow it after restoring the flag.
Adjust executor shutdown/cancellation flow if interruption during cleanup is unintended.
Retry the drop only after confirming the interruption source has stopped.

Example fix

// before
try { catalog.dropTable(id); } catch (RuntimeException e) { /* ignored */ }
// after
try {
  catalog.dropTable(id);
} catch (RuntimeException e) {
  if (e.getCause() instanceof InterruptedException) {
    Thread.currentThread().interrupt();
    throw e;
  }
  throw e;
}

Defensive patterns

Strategy: try-catch

Validate before calling

if (Thread.currentThread().isInterrupted()) {
  throw new InterruptedException("Interrupted before dropping table");
}

Try / catch

try {
  catalog.dropTable(id);
} catch (RuntimeException e) {
  if (e.getCause() instanceof InterruptedException) {
    Thread.currentThread().interrupt();
    // defer: re-check table existence later before retrying
    throw e;
  }
  throw e;
}

Prevention

After interruption, re-verify table state before retrying the drop.
Avoid killing threads mid-metadata-operation; use idempotent cleanup jobs.
Ensure shutdown hooks let in-flight metastore calls finish or abort cleanly.

When it happens

Trigger: Calling catalog.dropTable(identifier) from a thread that receives an interrupt (executor shutdown, task cancellation, kill) during the Thrift call to the metastore.

Common situations: Cancelling Spark/Flink jobs that drop staging tables; shutting down worker pools mid-cleanup; deadline-based cancellation implemented with interrupts.

Related errors

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