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
- Verify the statement was prepared in the same session (SHOW PREPARED STATEMENTS / check addPreparedStatement path)
- Fix application flow so DEALLOCATE only runs for names prepared earlier in the same connection
- 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
- Run DEALLOCATE on the same connection/session where PREPARE ran
- Make cleanup idempotent by tolerating NOT_FOUND
- Configure connection pools to reset prepared-statement state consistently on checkin/checkout
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.