prestodb/presto · critical · SQLException

Error fetching version from server

Error message

Error fetching version from server

What it means

Server info (including the server version) is lazily fetched from the coordinator via queryExecutor.getServerInfo(httpUri) and cached in serverInfo. Any RuntimeException from that HTTP exchange is wrapped and rethrown as SQLException("Error fetching version from server", e). It surfaces from any API that needs server capabilities when the coordinator is unreachable or its response is unusable.

Source

Thrown at presto-jdbc/src/main/java/com/facebook/presto/jdbc/PrestoConnection.java:748

    {
        return ImmutableMap.copyOf(sessionProperties);
    }

    @VisibleForTesting
    public Map<String, String> getCustomHeaders()
    {
        return ImmutableMap.copyOf(customHeaders);
    }

    ServerInfo getServerInfo()
            throws SQLException
    {
        if (serverInfo.get() == null) {
            try {
                serverInfo.set(queryExecutor.getServerInfo(httpUri));
            }
            catch (RuntimeException e) {
                throw new SQLException("Error fetching version from server", e);
            }
        }
        return serverInfo.get();
    }

    @VisibleForTesting
    List<QueryInterceptor> getQueryInterceptorInstances()
    {
        return queryInterceptorInstances;
    }

    boolean shouldStartTransaction()
    {
        return !autoCommit.get() && (transactionId.get() == null);
    }

    String getStartTransactionSql()
            throws SQLException

View on GitHub (pinned to 55bb57d202)

Solutions

  1. Verify the coordinator is reachable: curl http(s)://<host>:<port>/v1/info and fix networking/TLS/proxy errors
  2. Retry the triggering call with backoff — the fetch is lazy, so the next attempt re-issues getServerInfo and caches on success
  3. Inspect coordinator logs for 5xx or serialization errors on the info endpoint
  4. Confirm the connection is not reused after close/executor shutdown across threads

Example fix

// before
String ver = connection.getServerVersion(); // may throw on unreachable coordinator
// after
try {
    String ver = connection.getServerVersion();
} catch (SQLException e) {
    if ("Error fetching version from server".equals(e.getMessage())) {
        // coordinator unreachable: check network, retry with backoff
    }
    throw e;
}
Defensive patterns

Strategy: retry

Validate before calling

URL url = new URI(coordinatorUri + "/v1/info").toURL();
HttpURLConnection hc = (HttpURLConnection) url.openConnection();
hc.setConnectTimeout(3000);
if (hc.getResponseCode() != 200) {
    throw new IOException("coordinator unreachable: " + hc.getResponseCode());
}

Try / catch

try {
    String ver = connection.getServerVersion();
} catch (SQLException e) {
    if ("Error fetching version from server".equals(e.getMessage()) && attempt < 3) {
        // exponential backoff, then retry — lazy fetch re-runs on next call
    } else {
        throw e;
    }
}

Prevention

When it happens

Trigger: Calling getServerVersion()-style APIs (or anything touching getServerInfo) while the coordinator is down, returns HTTP 5xx, the response fails to parse, or a proxy/TLS problem breaks the /v1/info exchange; also after the underlying executor has been shut down by a closed connection.

Common situations: Coordinator behind a misconfigured load balancer; TLS/host mismatch; server restart or upgrade while connections are open; network partition after initial connect.

Related errors


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