prestodb/presto · error · PrestoException

NOT_FOUND

NOT_FOUND

Error message

Prepared statement not found: 

What it means

Thrown by QueryStateMachine.removePreparedStatement when DEALLOCATE targets a key not present in session.getPreparedStatements(). Presto tracks prepared statements per session; deallocating an unknown key raises NOT_FOUND and, note, the key would otherwise be added to deallocatedPreparedStatements.

Source

Thrown at presto-main-base/src/main/java/com/facebook/presto/execution/QueryStateMachine.java:733

    public Set<SqlFunctionId> getRemovedSessionFunctions()
    {
        return removedSessionFunctions;
    }

    public void addPreparedStatement(String key, String value)
    {
        requireNonNull(key, "key is null");
        requireNonNull(value, "value is null");

        addedPreparedStatements.put(key, value);
    }

    public void removePreparedStatement(String key)
    {
        requireNonNull(key, "key is null");

        if (!session.getPreparedStatements().containsKey(key)) {
            throw new PrestoException(NOT_FOUND, "Prepared statement not found: " + key);
        }
        deallocatedPreparedStatements.add(key);
    }

    public void addSessionFunction(SqlFunctionId signature, SqlInvokedFunction function)
    {
        requireNonNull(signature, "signature is null");
        requireNonNull(function, "function is null");

        if (session.getSessionFunctions().containsKey(signature) || addedSessionFunctions.putIfAbsent(signature, function) != null) {
            throw new PrestoException(ALREADY_EXISTS, format("Session function %s has already been defined", signature));
        }
    }

    public void removeSessionFunction(SqlFunctionId signature, boolean suppressNotFoundException)
    {
        requireNonNull(signature, "signature is null");

View on GitHub (pinned to 55bb57d202)

Solutions

  1. Verify the statement was prepared in the same session (SHOW PREPARED STATEMENTS / check addPreparedStatement path)
  2. Fix application flow so DEALLOCATE only runs for names prepared earlier in the same connection
  3. Guard DEALLOCATE calls to run once, or tolerate NOT_FOUND in the caller

Example fix

// before
DEALLOCATE PREPARE my_stmt; // prepared on another connection
// after
PREPARE my_stmt FROM SELECT 1; // same session first
DEALLOCATE PREPARE my_stmt;
Defensive patterns

Strategy: try-catch

Validate before calling

if (session.getPreparedStatements().containsKey(name)) {
    stateMachine.removePreparedStatement(name);
}

Try / catch

try { deallocate(name); } catch (PrestoException e) { if (e.getErrorCode().getCode() == StandardErrorCode.NOT_FOUND.toErrorCodeCode()) { /* already gone; idempotent no-op */ } else { throw e; } }

Prevention

When it happens

Trigger: Executing `DEALLOCATE PREPARE name` where name was never prepared in the current session, was already deallocated, or the session was replaced (new connection/connection pool handed a fresh session).

Common situations: Connection pool returning a different session than the one where PREPARE ran; DEALLOCATE executed twice; application restart clearing server-side prepared statements while client state persists.

Understand the failure class

Background: NOT_FOUND error code: why tRPC, Harbor, Nacos and other libraries return 404 "not found" errors for resources that may still exist — this error's family across 11 libraries.

Related errors


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