prestodb/presto · error · PrestoException

NO_NODES_AVAILABLE

NO_NODES_AVAILABLE

Error message

No nodes available to run query

What it means

In SimpleTtlNodeSelector.computeAssignments, when no candidate node has enough remaining TTL (per nodeTtlFetcherManager and the query's estimated remaining execution time) to safely host the split, and fallbackToSimpleNodeSelection is disabled, the selector throws NO_NODES_AVAILABLE. The query's estimated execution time exceeds every active worker's TTL confidence window, so TTL-aware scheduling refuses to place the split. The same condition falls back to SimpleNodeSelector when the fallback flag is enabled.

Source

Thrown at presto-main-base/src/main/java/com/facebook/presto/execution/scheduler/nodeSelection/SimpleTtlNodeSelector.java:208

        OptionalInt preferredNodeCount = OptionalInt.empty();
        for (Split split : splits) {
            if (split.getNodeSelectionStrategy() != NodeSelectionStrategy.NO_PREFERENCE) {
                throw new PrestoException(
                        NODE_SELECTION_NOT_SUPPORTED,
                        format("Unsupported node selection strategy for TTL scheduling: %s", split.getNodeSelectionStrategy()));
            }

            List<InternalNode> candidateNodes = randomNodeSelection.pickNodes(split);
            if (candidateNodes.isEmpty()) {
                Duration remainingTime = getEstimatedExecutionTimeRemaining();
                if (fallbackToSimpleNodeSelection) {
                    log.warn("No nodes available with enough TTL (%s) to schedule %s. Active nodes %s, falling back to simple node selection.", remainingTime, split, nodeMap.getActiveNodes());
                    return simpleNodeSelector.computeAssignments(splits, existingTasks);
                }

                log.warn("No nodes available with enough TTL (%s) to schedule %s. Active nodes %s", remainingTime, split, nodeMap.getActiveNodes());
                throw new PrestoException(NO_NODES_AVAILABLE, "No nodes available to run query");
            }

            SplitWeight splitWeight = split.getSplitWeight();
            Optional<InternalNodeInfo> chosenNodeInfo = simpleNodeSelector.chooseLeastBusyNode(
                    splitWeight,
                    candidateNodes,
                    assignmentStats::getTotalSplitsWeight,
                    preferredNodeCount,
                    maxSplitsWeightPerNode,
                    assignmentStats);
            if (!chosenNodeInfo.isPresent()) {
                chosenNodeInfo = simpleNodeSelector.chooseLeastBusyNode(
                        splitWeight, candidateNodes, assignmentStats::getQueuedSplitsWeightForStage, preferredNodeCount, maxPendingSplitsWeightPerTask, assignmentStats);
            }

            if (chosenNodeInfo.isPresent()) {
                split = new Split(
                        split.getConnectorId(),

View on GitHub (pinned to 55bb57d202)

Solutions

1. Enable the fallback: set node-scheduler.ttl-match-scheduler.fallback-to-simple-node-selection-when-serialization-time-not-available=true so scheduling falls back to SimpleNodeSelector instead of throwing.
2. Update the node TTL provider file/endpoint so workers report TTLs long enough for the workload, or shorten query resource estimates.
3. Check TTL fetcher configuration (ttl-match-scheduler providers / file paths) - missing TTL info means nodes are filtered out.
4. Reduce query size or split the workload so estimated execution time fits within node TTL windows.
5. Verify nodeTtlFetcherManager returns data (logs) and that nodes are actually active.

Example fix

// before (etc/config.properties)
// fallback disabled -> long queries throw NO_NODES_AVAILABLE

// after
node-scheduler.ttl-match-scheduler.fallback-to-simple-node-selection-when-serialization-time-not-available=true

// Ensure the TTL fallback is configured before using TTL scheduling
if (useTtlScheduling && !fallbackToSimpleNodeSelection) {
    throw new IllegalStateException("Enable node-scheduler.ttl-match-scheduler.fallback-to-simple-node-selection-when-serialization-time-not-available");
}

try {
    return ttlNodeSelector.computeAssignments(splits, existingTasks);
} catch (PrestoException e) {
    if (e.getErrorCode() == StandardErrorCode.NO_NODES_AVAILABLE.toErrorCode().getCode()) {
        log.warn("No TTL-eligible nodes; falling back to simple node selection");
        return simpleNodeSelector.computeAssignments(splits, existingTasks);
    }
    throw e;
}

When it happens

Trigger: TTL scheduling enabled with node-scheduler.ttl-match-scheduler.fallback-to-simple-node-selection-when-serialization-time-not-available=false (fallback off); the query's estimated execution time remaining is longer than every active node's reported TTL from the TTL fetchers; all eligible nodes filtered out by TTL or exhausted via maxTasksPerStage.

Common situations: Long-running queries (high estimated time) on a cluster whose workers report short TTLs in the TTL file; missing or stale TTL entries for some nodes so their TTL info is empty; misestimated execution time making all nodes ineligible; TTL fetcher misconfiguration so no node matches.

Related errors

• NO_NODES_AVAILABLE
• NODE_SELECTION_NOT_SUPPORTED
• NO_NODES_AVAILABLE
• Unknown cluster Ttl provider manager
• Query Prerequisites '%s' is already registered

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