prestodb/presto · error · PrestoException

GENERIC_INTERNAL_ERROR

GENERIC_INTERNAL_ERROR

Error message

Formatted query does not parse: 

What it means

Thrown by SqlFormatterUtil.getFormattedSql after it formats a Statement back to SQL and attempts to re-parse it with strict (REJECT) parsing options. If the formatted string does not parse, the formatter produced invalid SQL, indicating a bug in the SQL formatter or an unsupported syntax, so GENERIC_INTERNAL_ERROR is raised.

Source

Thrown at presto-main-base/src/main/java/com/facebook/presto/sql/SqlFormatterUtil.java:44

import static com.facebook.presto.spi.StandardErrorCode.GENERIC_INTERNAL_ERROR;
import static com.facebook.presto.sql.parser.ParsingOptions.DecimalLiteralTreatment.REJECT;

public final class SqlFormatterUtil
{
    private SqlFormatterUtil() {}

    public static String getFormattedSql(Statement statement, SqlParser sqlParser, Optional<List<Expression>> parameters)
    {
        String sql = SqlFormatter.formatSql(statement, parameters);

        // verify round-trip
        Statement parsed;
        try {
            ParsingOptions parsingOptions = new ParsingOptions(REJECT /* formatted SQL should be unambiguous */);
            parsed = sqlParser.createStatement(sql, parsingOptions);
        }
        catch (ParsingException e) {
            throw new PrestoException(GENERIC_INTERNAL_ERROR, "Formatted query does not parse: " + statement);
        }
        if (!statement.equals(parsed)) {
            throw new PrestoException(GENERIC_INTERNAL_ERROR, "Query does not round-trip: " + statement);
        }

        return sql;
    }
}

View on GitHub (pinned to 55bb57d202)

Solutions

1. Verify with a minimal repro and file/inspect a Presto bug against the SQL formatter for that statement type
2. Work around by formatting with the non-strict formatter (sqlFormatter.formatStatement) instead of relying on getFormattedSql
3. Upgrade Presto to a version where the formatter bug for that node type is fixed
4. Avoid calling getFormattedSql on programmatically constructed statements that don't originate from parsing

Example fix

// before
String sql = SqlFormatterUtil.getFormattedSql(statement, sqlParser);
// after
String sql = sqlFormatter.formatStatement(statement); // if strict round-trip not required

try { String sql = SqlFormatterUtil.getFormattedSql(statement, sqlParser); } catch (PrestoException e) { if (e.getErrorCode().getCode() == GENERIC_INTERNAL_ERROR.toErrorCode().getCode()) { return sqlParser + fallback: sqlFormatter.formatStatement(statement); } throw e; }

When it happens

Trigger: Calling SqlFormatterUtil.getFormattedSql(statement, sqlParser, ...) where statement.format(sqlFormatter) yields text that ParsingException-rejects under ParsingOptions(REJECT), e.g. formatting a node type the formatter handles incorrectly.

Common situations: Presto bug in SqlFormatter for newer/edge-case AST nodes; custom statements built programmatically; calling the util on statements the formatter was never designed to emit round-trippably.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors

• INVALID_TABLE_PROPERTY
• GENERIC_INTERNAL_ERROR
• Invalid time from server:
• Expected column to be a time type but is
• Invalid timestamp from server:

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