prestodb/presto · error · PrestoException

NO_NODES_AVAILABLE

NO_NODES_AVAILABLE

Error message

No assignment for split in bucketNodeMap. Split Info: %s

What it means

NO_NODES_AVAILABLE failure in NodeScheduler.selectDistributionNodes: a bucketed split's bucketNodeMap maps its bucket to no active node (typically because the mapped node left the cluster or the map was built against a stale node set), so the split cannot be assigned anywhere.

Source

Thrown at presto-main-base/src/main/java/com/facebook/presto/execution/scheduler/NodeScheduler.java:425

            NodeMap nodeMap,
            NodeTaskMap nodeTaskMap,
            long maxSplitsWeightPerNode,
            long maxPendingSplitsWeightPerTask,
            int maxUnacknowledgedSplitsPerTask,
            Set<Split> splits,
            List<RemoteTask> existingTasks,
            BucketNodeMap bucketNodeMap,
            NodeSelectionStats nodeSelectionStats)
    {
        Multimap<InternalNode, Split> assignments = HashMultimap.create();
        NodeAssignmentStats assignmentStats = new NodeAssignmentStats(nodeTaskMap, nodeMap, existingTasks);

        Set<InternalNode> blockedNodes = new HashSet<>();
        for (Split split : splits) {
            // node placement is forced by the bucket to node map
            Optional<InternalNode> optionalNode = bucketNodeMap.getAssignedNode(split);
            if (!optionalNode.isPresent()) {
                throw new PrestoException(NO_NODES_AVAILABLE, format("No assignment for split in bucketNodeMap. Split Info: %s", split.getConnectorSplit().getInfoMap()));
            }
            InternalNode node = optionalNode.get();
            boolean isCacheable = bucketNodeMap.isSplitCacheable(split);
            SplitWeight splitWeight = split.getSplitWeight();

            // if node is full, don't schedule now, which will push back on the scheduling of splits
            if (canAssignSplitToDistributionNode(assignmentStats, node, maxSplitsWeightPerNode, maxPendingSplitsWeightPerTask, maxUnacknowledgedSplitsPerTask, splitWeight)) {
                if (isCacheable) {
                    split = new Split(split.getConnectorId(), split.getTransactionHandle(), split.getConnectorSplit(), split.getLifespan(), new SplitContext(true));
                    nodeSelectionStats.incrementBucketedPreferredNodeSelectedCount();
                }
                else {
                    nodeSelectionStats.incrementBucketedNonPreferredNodeSelectedCount();
                }
                assignments.put(node, split);
                assignmentStats.addAssignedSplit(node, splitWeight);
            }
            else {

View on GitHub (pinned to 55bb57d202)

Solutions

  1. Retry the query after the cluster node set stabilizes
  2. Check for recently dead/restarting workers and their re-registration
  3. If persistent, restart the coordinator so bucket-to-node mappings are rebuilt
  4. Verify all workers in the bucket mapping are healthy and not blacklisted
Defensive patterns

Strategy: retry

When it happens

Trigger: Thrown at presto-main-base/src/main/java/com/facebook/presto/execution/scheduler/NodeScheduler.java:425 when the library encounters an invalid state.

Common situations: See trigger scenarios.


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