What causes "No nodes available to run query" in prestodb/presto?

Verify worker processes are running and registered (coordinator UI /age/most recent heartbeats)

prestodb/presto · critical · PrestoException

NO_NODES_AVAILABLE

NO_NODES_AVAILABLE

Error message

No nodes available to run query

What it means

NodeManager.getRequiredWorkerNodes() fetches the set of active worker nodes and throws PrestoException with code NO_NODES_AVAILABLE if none exist. The coordinator cannot schedule any query work without workers, so it fails the operation immediately with this explicit message rather than producing an unrunnable plan.

Source

Thrown at presto-spi/src/main/java/com/facebook/presto/spi/NodeManager.java:36

import static com.facebook.presto.spi.StandardErrorCode.NO_NODES_AVAILABLE;

public interface NodeManager
{
    Set<Node> getAllNodes();

    Set<Node> getWorkerNodes();

    Node getCurrentNode();

    Node getSidecarNode();

    String getEnvironment();

    default Set<Node> getRequiredWorkerNodes()
    {
        Set<Node> nodes = getWorkerNodes();
        if (nodes.isEmpty()) {
            throw new PrestoException(NO_NODES_AVAILABLE, "No nodes available to run query");
        }
        return nodes;
    }
}

View on GitHub (pinned to 55bb57d202)

Solutions

Verify worker processes are running and registered (coordinator UI /age/most recent heartbeats)
Check discovery.uri on workers points at the coordinator and both sides share the same node.environment
Check network connectivity/ports between workers and coordinator (discovery port, HTTP port)
Inspect coordinator logs for worker shutdown/heartbeat-expiry reasons and restart workers
For rolling restarts, keep sufficient workers up or pause query submission

Example fix

# before (worker etc/node.properties)
node.environment=production
discovery.uri=http://wrong-host:8080
# after
node.environment=production
discovery.uri=http://coordinator:8080

Defensive patterns

Strategy: retry

Validate before calling

Set<Node> workers = nodeManager.getWorkerNodes();
if (workers.isEmpty()) {
    throw new PrestoException(NO_NODES_AVAILABLE, "No workers registered; check worker discovery.uri and node.environment");
}

Try / catch

try {
    nodes = nodeManager.getRequiredWorkerNodes();
} catch (PrestoException e) {
    if (e.getErrorCode().getCode() == NO_NODES_AVAILABLE.getCode()) {
        // wait/backoff for workers to register, then retry
        scheduleRetryWithBackoff();
    } else {
        throw e;
    }
}

Prevention

Monitor active worker count and alert before it hits zero
Verify node.environment and discovery.uri match across coordinator and workers
Use failure detection thresholds so one flapped heartbeat doesn't empty the pool
Configure enough workers/rolling restarts to keep capacity available

When it happens

Trigger: Calling getRequiredWorkerNodes() (directly or via query scheduling) while getWorkerNodes() returns an empty set — all workers shut down, failed heartbeats, node URI/environment mismatch filtering them out.

Common situations: Workers not started or crashed at coordinator startup; discovery URI misconfigured so workers register elsewhere; network/firewall blocking heartbeat ports; internalCommunication environment names differing between coordinator and workers; all workers retired during rolling restart with min worker count unmet.

Related errors

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