apache/iceberg · error · UncheckedInterruptedException

Interrupted during commit

Error message

Interrupted during commit

What it means

doCommit catches InterruptedException thrown while waiting on the connection pool / commit execution and rethrows it as UncheckedInterruptedException('Interrupted during commit') after restoring the thread's interrupt flag. This signals the commit did not complete because the calling thread was interrupted, and it propagates the interruption politely.

Source

Thrown at core/src/main/java/org/apache/iceberg/jdbc/JdbcViewOperations.java:134

    } catch (SQLTransientConnectionException | SQLNonTransientConnectionException e) {
      throw new UncheckedSQLException(e, "Database Connection failed");
    } catch (DataTruncation e) {
      throw new UncheckedSQLException(e, "Database data truncation error");
    } catch (SQLWarning e) {
      throw new UncheckedSQLException(e, "Database warning");
    } catch (SQLException e) {
      if (JdbcUtil.isConstraintViolation(e)) {
        if (currentMetadataLocation() == null) {
          throw new AlreadyExistsException(e, "View already exists: %s", viewIdentifier);
        } else {
          throw new UncheckedSQLException(e, "View already exists: %s", viewIdentifier);
        }
      }

      throw new UncheckedSQLException(e, "Unknown failure");
    } catch (InterruptedException e) {
      Thread.currentThread().interrupt();
      throw new UncheckedInterruptedException(e, "Interrupted during commit");
    }
  }

  @Override
  protected String viewName() {
    return viewIdentifier.toString();
  }

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

  private void validateMetadataLocation(Map<String, String> view, ViewMetadata base) {
    String catalogMetadataLocation = view.get(JdbcTableOperations.METADATA_LOCATION_PROP);
    String baseMetadataLocation = base != null ? base.metadataFileLocation() : null;

    if (!Objects.equals(baseMetadataLocation, catalogMetadataLocation)) {

View on GitHub (pinned to 86d9c8fc54)

Solutions

  1. Treat the commit as not applied and re-plan; check the catalog to see whether the view metadata was actually written before retrying
  2. Propagate or handle the interruption rather than swallowing it — the interrupt flag is already restored by the library
  3. Avoid interrupting threads that are in the middle of catalog commits; use cancellation points outside commit
  4. Retry the commit after shutdown/cancellation resolves, since JDBC commit is atomic via conditional UPDATE
  5. Investigate what issued the interrupt (executor shutdown, cancel(true)) and fix the lifecycle

Example fix

// before
executor.submit(() -> viewOps.commit(req)); // cancelled via future.cancel(true)
// after: let commits finish or check state before retry
boolean done = future.await(30, TimeUnit.SECONDS);
if (!done) {
  // verify catalog state before re-committing
}
Defensive patterns

Strategy: try-catch

Try / catch

try {
  viewOps.commit(request);
} catch (UncheckedInterruptedException e) {
  // interrupt flag already restored by the library
  Thread.currentThread().interrupt();
  throw new CommitAbortedException(viewId, e);
}

Prevention

When it happens

Trigger: The thread performing JdbcViewOperations.commit() (which internally uses connectionPool ConnectionProvider and can block acquiring connections or executing SQL) is interrupted — e.g. query/task cancellation, executor shutdown, or a timeout mechanism that interrupts worker threads.

Common situations: Spark/Flink task cancellation mid-commit; application shutdown while a view commit is in flight; a wrapper setting a thread timeout and calling Future.cancel(true).

Understand the failure class

Background: Request timed out: what client-side request timeouts mean across libraries (Request timed out, TIMED_OUT, APITimeoutError) — this error's family across 39 libraries.

Related errors


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