prestodb/presto · error · IllegalStateException

Query is gone (server restarted?)

Error message

Query is gone (server restarted?)

What it means

In the plan-checker router plugin, the internal Presto client that runs the native-compatibility verification query reports a client-side error state. The scheduler treats this as evidence the query no longer exists on the coordinator it was submitted to, typically because that coordinator restarted and lost the in-memory query, so the compatibility check cannot complete.

Source

Thrown at presto-plan-checker-router-plugin/src/main/java/com/facebook/presto/router/scheduler/PlanCheckerRouterPluginPrestoClient.java:104

        boolean isNativeCompatible = true;
        // submit initial query
        try (StatementClient client = newStatementClient(httpClient, clientSession, newSql)) {
            // read query output
            while (client.isRunning()) {
                log.debug((client.currentData().toString()));

                if (!client.advance()) {
                    break;
                }
            }

            // verify final state
            if (client.isClientAborted()) {
                throw new IllegalStateException("Query aborted by user");
            }

            if (client.isClientError()) {
                throw new IllegalStateException("Query is gone (server restarted?)");
            }

            verify(client.isFinished());
            QueryError resultsError = client.finalStatusInfo().getError();
            if (resultsError != null) {
                isNativeCompatible = false;
                log.info(resultsError.getMessage());
            }
        }
        catch (Exception e) {
            if (javaClusterFallbackEnabled) {
                // If any exception is thrown, log the message and re-route to a Java clusters router.
                isNativeCompatible = false;
                log.info(e.getMessage());
                fallBackToJavaClusterRedirectRequests.update(1L);
            }
            else {
                // hard failure

View on GitHub (pinned to 55bb57d202)

Solutions

  1. Retry the compatibility probe against the same or another cluster after the coordinator comes back healthy
  2. Check coordinator logs around the restart to confirm the query was lost and fix the underlying crash/OOM
  3. Make the router prefer clusters with stable coordinators or add health checks before probing
  4. Update the router to distinguish 'query gone due to restart' from genuine client errors and treat it as retryable

Example fix

// before
if (client.isClientError()) {
    throw new IllegalStateException("Query is gone (server restarted?)");
}
// after
if (client.isClientError()) {
    if (retryCount < MAX_RETRIES) {
        return getCompatibleClusterURI(query, retryCount + 1); // coordinator restarted; resubmit
    }
    throw new IllegalStateException("Query is gone (server restarted?)");
}
Defensive patterns

Strategy: retry

Validate before calling

// before probing, verify the target coordinator is reachable and healthy
// curl -s http://coordinator:8080/v1/status | jq -s 'length > 0'

Try / catch

try {
    URI cluster = getCompatibleClusterURI(query);
} catch (IllegalStateException e) {
    if (e.getMessage().contains("Query is gone")) {
        // coordinator restarted: retry or fail over to another cluster
    } else {
        throw e;
    }
}

Prevention

When it happens

Trigger: getCompatibleClusterURI submits a query via the internal client; the client later reports isClientError() at the final-state verification, e.g. the target coordinator restarted or failed over between submit and fetch, or the query was dropped/expired server-side.

Common situations: Rolling restarts of Presto coordinators behind the router; a coordinator crash mid-query; submitting to a cluster that reaped the query before the client polled final status.

Related errors


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