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
- No immediate action needed for the counted successes; the failed files remain in the batch and are retried on the next delete cycle
- Check object-store side errors (throttling, permissions) in the nested exception and raise request rate limits or fix ACLs
- Avoid running concurrent maintenance jobs that delete the same files
- 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
- Raise object-store request-rate limits to survive bulk deletes
- Fix ACLs/IAM so the task identity can delete all data prefixes
- Don't run competing orphan-cleanup jobs concurrently with rewrite cleanup
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
- Deleted only {} of {} files from table {} using bulk deletes
- Deleted only {} of {} files from table {} using bulk deletes
- Failed to delete uncommitted DV {} for table {} task {}
- Failed to delete: {}
- The iceberg transaction has been committed, but we failed to
AI-assisted analysis of apache/iceberg@86d9c8fc54 (2026-09-12).
Data as JSON: /api/errors/24ac6cd9c05252f1.
Report an issue: GitHub.