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 failureView on GitHub (pinned to 55bb57d202)
Solutions
- Retry the compatibility probe against the same or another cluster after the coordinator comes back healthy
- Check coordinator logs around the restart to confirm the query was lost and fix the underlying crash/OOM
- Make the router prefer clusters with stable coordinators or add health checks before probing
- 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
- Add coordinator health checks before submitting probe queries
- Treat client-error-on-final-state as retryable with bounded retries
- Monitor coordinator restarts and route away from flapping coordinators
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
- Cannot install coordinator plugins on router
- Failed to build plugin classloaders
- INVALID_TABLE_PROPERTY
- ACCUMULO_TABLE_EXISTS
- NOT_SUPPORTED
AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04).
Data as JSON: /api/errors/e8866c451cf96917.
Report an issue: GitHub.