prestodb/presto · error · PrestoException

GENERIC_USER_ERROR

GENERIC_USER_ERROR

Error message

GENERIC_USER_ERROR: failureInfo.toException() (decoded failure thrown to user via fail() function)

What it means

The hidden SQL fail(json) function deserializes a serialized FailureInfo (PrestoException JSON) and throws it as a new PrestoException wrapped in GENERIC_USER_ERROR. This is how Presto propagates an error that occurred during query optimization back to the user at execution time, appending the current stack trace. Seeing this message means the original error was deliberately deferred from planning and re-thrown here.

Source

Thrown at presto-main-base/src/main/java/com/facebook/presto/operator/scalar/FailureFunction.java:42

import io.airlift.slice.Slice;

import static com.facebook.presto.spi.function.SqlFunctionVisibility.HIDDEN;

public final class FailureFunction
{
    private static final JsonCodec<FailureInfo> JSON_CODEC = JsonCodec.jsonCodec(FailureInfo.class);

    private FailureFunction() {}

    // We shouldn't be using UNKNOWN as an explicit type. This will be fixed when we fix type inference
    @Description("Decodes json to an exception and throws it")
    @ScalarFunction(value = "fail", visibility = HIDDEN)
    @SqlType("unknown")
    public static boolean failWithException(@SqlType(StandardTypes.JSON) Slice failureInfoSlice)
    {
        FailureInfo failureInfo = JSON_CODEC.fromJson(failureInfoSlice.getBytes());
        // wrap the failure in a new exception to append the current stack trace
        throw new PrestoException(StandardErrorCode.GENERIC_USER_ERROR, failureInfo.toException());
    }

    // This function is only used to propagate optimization failures.
    @Description("Decodes json to an exception and throws it with supplied errorCode")
    @ScalarFunction(value = "fail", visibility = HIDDEN)
    @SqlType("unknown")
    public static boolean failWithException(
            @SqlType(StandardTypes.INTEGER) long errorCode,
            @SqlType(StandardTypes.JSON) Slice failureInfoSlice)
    {
        FailureInfo failureInfo = JSON_CODEC.fromJson(failureInfoSlice.getBytes());
        // wrap the failure in a new exception to append the current stack trace
        for (StandardErrorCode standardErrorCode : StandardErrorCode.values()) {
            if (standardErrorCode.toErrorCode().getCode() == errorCode) {
                throw new PrestoException(standardErrorCode, failureInfo.toException());
            }
        }
        throw new PrestoException(StandardErrorCode.GENERIC_INTERNAL_ERROR, "Unable to find error for code: " + errorCode, failureInfo.toException());

View on GitHub (pinned to 55bb57d202)

Solutions

  1. Read the inner failureInfo message/stack in the error to find the original optimization failure and fix its root cause.
  2. Inspect the query fragment containing the injected fail(json) call to identify which expression triggered the deferred error.
  3. If calling fail() manually, pass a valid JSON FailureInfo produced by serializing a PrestoException, not arbitrary JSON.

Example fix

// before
SELECT fail('{"message":"some error"}')
// after
-- fix the underlying expression instead of relying on the deferred failure
Defensive patterns

Strategy: try-catch

Validate before calling

// SQL: avoid reaching the injected fail(json) by validating inputs at query build time
-- ensure literals/arguments passed the planner checks before execution

Try / catch

// client
try {
    executeQuery(sql);
} catch (QueryFailedException e) {
    if (e.getErrorCode().getCode() == StandardErrorCode.GENERIC_USER_ERROR.toErrorCode().getCode()) {
        // inspect failureInfo in the failure JSON for the original cause
    }
}

Prevention

When it happens

Trigger: A query calls fail(json_failure_info) (internally injected by the optimizer when an error is raised during planning via the FailFunction), where the JSON argument decodes to a FailureInfo. The decoded failure is then thrown with code GENERIC_USER_ERROR regardless of the original code.

Common situations: Developers hit this when a query plan contains a fail() call injected for an optimization-time error: bad literal usage, unsupported function arguments, or a type error detected during planning that surfaces only when the fragment executes. It also appears when hand-crafting SQL that calls fail() with a serialized exception JSON.

Related errors

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