apache/iceberg · warning

Failed to delete {} ({})

Error message

Failed to delete {} ({})

What it means

Not a thrown exception but a WARN log emitted by SparkCleanupUtil.deleteFiles when the per-file delete task fails after retries. Tasks.foreach retries each path DELETE_NUM_RETRIES times with exponential backoff, stopping early only on NotFoundException; when a path still fails to delete, it is logged with the failure context. Orphan data files may be left behind and require an orphan-file cleanup procedure.

Source

Thrown at spark/v4.2/spark/src/main/java/org/apache/iceberg/spark/source/SparkCleanupUtil.java:101

   * @param files a list of files to delete
   */
  public static void deleteFiles(String context, FileIO io, List<? extends ContentFile<?>> files) {
    List<String> paths = Lists.transform(files, ContentFile::location);
    if (io instanceof SupportsBulkOperations) {
      CatalogUtil.deleteFiles(io, paths, "");
    } else {
      delete(context, io, paths);
    }
  }

  private static void delete(String context, FileIO io, List<String> paths) {
    AtomicInteger deletedFilesCount = new AtomicInteger(0);

    Tasks.foreach(paths)
        .executeWith(ThreadPools.getWorkerPool())
        .stopRetryOn(NotFoundException.class)
        .suppressFailureWhenFinished()
        .onFailure((path, exc) -> LOG.warn("Failed to delete {} ({})", path, context, exc))
        .retry(DELETE_NUM_RETRIES)
        .exponentialBackoff(
            DELETE_MIN_RETRY_WAIT_MS,
            DELETE_MAX_RETRY_WAIT_MS,
            DELETE_TOTAL_RETRY_TIME_MS,
            2 /* exponential */)
        .run(
            path -> {
              io.deleteFile(path);
              deletedFilesCount.incrementAndGet();
            });

    if (deletedFilesCount.get() < paths.size()) {
      LOG.warn("Deleted only {} of {} file(s) ({})", deletedFilesCount, paths.size(), context);
    } else {
      LOG.info("Deleted {} file(s) ({})", paths.size(), context);
    }
  }

View on GitHub (pinned to 86d9c8fc54)

Solutions

  1. Check the logged path and the wrapped exception cause for the actual delete error
  2. Run an orphan-file cleanup (removeOrphanFiles) to remove any files left behind
  3. Verify FileIO credentials/permissions are valid for the file locations
  4. If caused by throttling, reduce delete parallelism or retry frequency
Defensive patterns

Strategy: retry

Prevention

When it happens

Trigger: Delete of data files during job/task abort where io.deleteFile(path) throws a transient or permanent IO exception (network blip to object store, credentials expiring mid-delete, throttling from S3/GCS, or a non-NotFoundException persistent error) after exhausting retries.

Common situations: Object-store throttling (S3 503s) during large aborts; expired cloud credentials on long-running jobs; files already deleted by a concurrent operation; misconfigured FileIO with wrong endpoint.

Related errors


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