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
- Check the logged path and the wrapped exception cause for the actual delete error
- Run an orphan-file cleanup (removeOrphanFiles) to remove any files left behind
- Verify FileIO credentials/permissions are valid for the file locations
- If caused by throttling, reduce delete parallelism or retry frequency
Defensive patterns
Strategy: retry
Prevention
- Ensure FileIO credentials remain valid for the job duration
- Pre-empt object-store throttling by reducing delete concurrency
- Schedule periodic removeOrphanFiles to reconcile leaked files
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
- Failed to delete {} ({})
- Deleted only {} of {} file(s) ({})
- Deleted only {} of {} file(s) ({})
- Failed to delete: {}
- Failed to delete: {}
AI-assisted analysis of apache/iceberg@86d9c8fc54 (2026-09-12).
Data as JSON: /api/errors/db7d01ce3e2f4784.
Report an issue: GitHub.