prestodb/presto · error · PinotException

PINOT_INSUFFICIENT_SERVER_RESPONSE

PINOT_INSUFFICIENT_SERVER_RESPONSE

Error message

Only %s out of %s servers responded for query %s

What it means

Thrown when a Pinot broker query response reports fewer servers responded (numServersResponded) than servers queried (numServersQueried), meaning some Pinot servers failed to answer the query. The Presto Pinot connector treats partial responses as untrustworthy results and fails the query rather than returning incomplete data.

Source

Thrown at presto-pinot-toolkit/src/main/java/com/facebook/presto/pinot/PinotBrokerPageSource.java:282

            if (result == null || result.size() < blockBuilders.size()) {
                throw new PinotException(
                    PINOT_UNEXPECTED_RESPONSE,
                    Optional.of(query),
                    String.format("Expected row of %d columns", blockBuilders.size()));
            }
            for (int columnNumber = 0; columnNumber < blockBuilders.size(); columnNumber++) {
                setValue(types.get(columnNumber), blockBuilders.get(columnNumber), result.get(columnNumber));
            }
        }
    }

    protected static void handleCommonResponse(String pinotQuery, JsonNode jsonBody)
    {
        JsonNode numServersResponded = jsonBody.get("numServersResponded");
        JsonNode numServersQueried = jsonBody.get("numServersQueried");

        if (numServersQueried == null || numServersResponded == null || numServersQueried.asInt() > numServersResponded.asInt()) {
            throw new PinotException(
                PINOT_INSUFFICIENT_SERVER_RESPONSE,
                Optional.of(pinotQuery),
                String.format("Only %s out of %s servers responded for query %s", numServersResponded.asInt(), numServersQueried.asInt(), pinotQuery));
        }

        JsonNode exceptions = jsonBody.get("exceptions");
        if (exceptions != null && exceptions.isArray() && exceptions.size() > 0) {
            if (exceptions.get(0).get("errorCode").asInt() == 180) {
                throw new PinotException(
                    PINOT_UNAUTHENTICATED_EXCEPTION,
                    Optional.empty(),
                    "Query authentication failed.");
            }
            // Pinot is known to return exceptions with benign errorcodes like 200
            // so we treat any exception as an error
            throw new PinotException(
                PINOT_EXCEPTION,
                Optional.of(pinotQuery),

View on GitHub (pinned to 55bb57d202)

Solutions

1. Check Pinot server logs for the servers that did not respond; look for timeouts, GC pauses, or crashes during the query window
2. Reduce query cost (add selective filters, limit columns, use LIMIT) so servers respond within the timeout
3. Increase Pinot server/broker timeouts (query.timeoutMs on broker, server timeout configs) via Pinot cluster config
4. Retry the query; transient server restarts often resolve on a second attempt
5. Verify Pinot cluster health (all servers up, segment replication adequate) before rerunning the query

Example fix

// before: query scans a large table with no filter, servers time out
SELECT * FROM myTable WHERE ts > 0
// after: constrain the query so all servers respond in time
SELECT colA, colB FROM myTable WHERE ts BETWEEN '2024-01-01' AND '2024-01-02' LIMIT 1000

// No pre-call check possible; check Pinot cluster health before query
// e.g. verify all Pinot servers are live via controller /health or cluster state

try {
    connector.query(sql);
} catch (PinotException e) {
    if (e.getErrorCode() == PinotErrorCode.PINOT_INSUFFICIENT_SERVER_RESPONSE) {
        // wait/backoff then retry; alert if persistent
    }
}

When it happens

Trigger: handleCommonResponse is called from populateFromQueryResults after parsing the broker response JSON; it throws when numServersQueried or numServersResponded is missing from the response body, or numServersQueried > numServersResponded (e.g. some Pinot servers timed out, crashed, or were restarted mid-query).

Common situations: Pinot server timeouts on heavy queries, a server being restarted or OOM-killed during a query, network partitions between broker and servers, oversized segment scans exceeding server timeouts.

Related errors

• ATOP_READ_TIMEOUT
• Timed out waiting for query preprocessor after
• Error fetching next (attempts: %s, duration: %s)
• INDEX_LOADER_TIMEOUT
• QUERY_PLANNING_TIMEOUT

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