apache/iceberg · warning

Deleted only {} of {} files from table {} using bulk deletes

Error message

Deleted only {} of {} files from table {} using bulk deletes

What it means

Logged by DeleteFilesProcessor when a BulkDeletionFailureException is caught during bulk file deletion: the FileIO's bulk delete partially succeeded, deleting only `deletedFilesCount` of the requested files. The processor counts the succeeded files, keeps the remainder in filesToDelete for a later retry, and logs which table was affected. This is expected behavior of FileIO.bulkDelete implementations (e.g. S3/Hadoop) that report per-object failures.

Source

Thrown at flink/v2.2/flink/src/main/java/org/apache/iceberg/flink/maintenance/operator/DeleteFilesProcessor.java:111

  public void processWatermark(Watermark mark) {
    deleteFiles();
  }

  @Override
  public void prepareSnapshotPreBarrier(long checkpointId) {
    deleteFiles();
  }

  private void deleteFiles() {
    try {
      io.deleteFiles(filesToDelete);
      LOG.info(
          "Deleted {} files from table {} using bulk deletes", filesToDelete.size(), tableName);
      succeededCounter.inc(filesToDelete.size());
      filesToDelete.clear();
    } catch (BulkDeletionFailureException e) {
      int deletedFilesCount = filesToDelete.size() - e.numberFailedObjects();
      LOG.warn(
          "Deleted only {} of {} files from table {} using bulk deletes",
          deletedFilesCount,
          filesToDelete.size(),
          tableName,
          e);
      succeededCounter.inc(deletedFilesCount);
      failedCounter.inc(e.numberFailedObjects());
    }
  }
}

View on GitHub (pinned to 86d9c8fc54)

Solutions

  1. No immediate action needed for the counted successes; the failed files remain in the batch and are retried on the next delete cycle
  2. Check object-store side errors (throttling, permissions) in the nested exception and raise request rate limits or fix ACLs
  3. Avoid running concurrent maintenance jobs that delete the same files
  4. If failures persist, delete files individually (non-bulk path) to isolate the problematic objects
Defensive patterns

Strategy: retry

Try / catch

// Processor already retries remaining files internally; user side:
// monitor succeeded vs total counts in metrics and alert on persistent shortfalls

Prevention

When it happens

Trigger: Raised in DeleteFilesProcessor.deleteFiles (called from processElement, processWatermark, prepareSnapshotPreBarrier) when FileIO.bulkDelete throws BulkDeletionFailureException with numberFailedObjects() > 0 — i.e. some objects in the batch could not be deleted from the object store/filesystem.

Common situations: S3 eventual-consistency/rate-limiting during large bulk deletes; permission errors on some prefixes; files already deleted by a concurrent orphan-cleanup or compaction job; transient 503s from the object store under load.

Related errors


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