apache/iceberg · error · UnsupportedOperationException

This implementation does not support providing an ExecutorSe

Error message

This implementation does not support providing an ExecutorService.

What it means

RewriteTablePath.executeWith(ExecutorService) lets callers parallelize metadata rewriting during a table-copy/rewrite-path action. The interface default throws UnsupportedOperationException; implementations that only support sequential metadata rewriting keep the stub.

Source

Thrown at api/src/main/java/org/apache/iceberg/actions/RewriteTablePath.java:117

   * <p>The default value is true, which means the file list will be created. If set to false, the
   * file list will not be created.
   *
   * @param createFileList true to create the file list, false to skip it
   * @return this instance for method chaining
   */
  default RewriteTablePath createFileList(boolean createFileList) {
    return this;
  }

  /**
   * Passes an alternative executor service that will be used for version file and manifest list
   * rewriting. If this method is not called, these operations will be performed sequentially.
   *
   * @param executorService an executor service to parallelize metadata rewriting
   * @return this for method chaining
   */
  default RewriteTablePath executeWith(ExecutorService executorService) {
    throw new UnsupportedOperationException(
        "This implementation does not support providing an ExecutorService.");
  }

  /** The action result that contains a summary of the execution. */
  interface Result {
    /** Staging location of rewritten files */
    String stagingLocation();

    /**
     * Result file list location. This file contains a listing of all files added to the table
     * between startVersion and endVersion, comma-separated. <br>
     * For each file, it will include the source path (either the original path in the table, or in
     * the staging location if rewritten), and the target path (under the new prefix).
     *
     * <p>Example file content:
     *
     * <pre><code>
     * sourcepath/datafile1.parquet,targetpath/datafile1.parquet

View on GitHub (pinned to 86d9c8fc54)

Solutions

Remove executeWith(...) and let the rewrite proceed sequentially
Use an implementation that supports executor-based parallelism
Parallelize at a higher level (e.g. copy partitions concurrently) instead of configuring the action's executor
Check for an override of executeWith on the concrete class before calling it

Example fix

// before
RewriteTablePath.Result r = actions.rewriteTablePath(table)
    .executeWith(executorService)
    .execute();
// after
RewriteTablePath.Result r = actions.rewriteTablePath(table)
    .execute(); // sequential metadata rewriting

Defensive patterns

Strategy: try-catch

Try / catch

try {
  builder.executeWith(executorService);
} catch (UnsupportedOperationException e) {
  // accept sequential rewriting
}

Prevention

Assume RewriteTablePath metadata rewriting is sequential unless documented otherwise
Parallelize externally (per-partition jobs) instead of relying on the action's executor
Check for executeWith overrides in the concrete implementation
Benchmark sequential performance before investing in executor tuning

When it happens

Trigger: Calling rewriteTablePath.executeWith(executorService) on an implementation that has not overridden the default method, attempting to parallelize staging/metadata rewriting.

Common situations: Users speeding up large table copies across locations/catalogs assume all RewriteTablePath implementations accept an executor; sequential-only bindings reject the configuration.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

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