What causes "Spilling failed: %s" in prestodb/presto?

Check the wrapped cause (prestoException.getCause()) and worker logs for the underlying IOException/root error.

prestodb/presto · error · PrestoException

GENERIC_SPILL_FAILURE

GENERIC_SPILL_FAILURE

Error message

Spilling failed: %s

What it means

GENERIC_SPILL_FAILURE is the wrapper Presto throws in SpillingUtils.checkSpillSucceeded when a spilling operation's future completes with a RuntimeException that is not already a PrestoException. Spill operations (aggregations, joins, orderings) run asynchronously; any unexpected exception while writing/reading spill files is rethrown with this error code and the original message preserved.

Source

Thrown at presto-main-base/src/main/java/com/facebook/presto/operator/SpillingUtils.java:43

{
    private SpillingUtils() {}

    /**
     * We use this instead of checkSuccess in airlift so we can propagate the error message
     * and so that we throw a PrestoException rather than an IllegalArgumentException.
     *
     * @param spillInProgress
     */
    public static void checkSpillSucceeded(Future spillInProgress)
    {
        try {
            getFutureValue(spillInProgress);
        }
        catch (PrestoException prestoException) {
            throw new PrestoException(prestoException::getErrorCode, prestoException.getMessage(), prestoException);
        }
        catch (RuntimeException runtimeException) {
            throw new PrestoException(GENERIC_SPILL_FAILURE, format("Spilling failed: %s", runtimeException.getMessage()), runtimeException);
        }
    }
}

View on GitHub (pinned to 55bb57d202)

Solutions

Check the wrapped cause (prestoException.getCause()) and worker logs for the underlying IOException/root error.
Verify the spill-path configuration (spiller spill-out-dir / spill filesystem properties) exists and is writable on all workers.
Free disk space or enlarge spill volumes; monitor disk usage on workers.
Run a smaller query to confirm spill infrastructure works; use retry or reduce memory limits if needed.
If the cause is a bug in a custom spiller/filesystem client, fix it or report upstream.

Defensive patterns

Strategy: try-catch

Validate before calling

// pre-flight: ensure spill path is writable on workers before heavy queries
// (run via admin):
//   hadoop fs -test -e <spill-path>  /  test -w <local spill dir>
// and confirm free space exceeds expected spill size

Try / catch

try {
    executeSpillingQuery();
} catch (PrestoException e) {
    if ("GENERIC_SPILL_FAILURE".equals(e.getErrorCode().getName())) {
        Throwable cause = e.getCause();
        log.warning("spill failed: " + (cause == null ? e : cause.getMessage()));
        // inspect disk space / spill-path config, then retry
        throw e;
    }
    throw e;
}

Prevention

Verify spill-path is valid and writable on every worker before running memory-heavy queries
Monitor worker disk usage and alert before volumes fill
Inspect getCause() to distinguish disk-full vs config vs code errors
Tune memory limits so spill volume stays within provisioned disk

When it happens

Trigger: A spill future passed to checkSpillSucceeded completes exceptionally with a non-PrestoException RuntimeException — e.g. IOException from the spill filesystem, disk full, filesystem unavailable, or a coding error in a custom spiller.

Common situations: Spill path (spiller spill-out directory) misconfigured, pointing to a nonexistent or unwritable location; disk full on workers; HDFS/local-FS issues; query memory limits forcing spill on clusters with broken spill storage.

Related errors

AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04). Data as JSON: /api/errors/1f6c2c508b64cf5a. Report an issue: GitHub.