apache/druid · error · IllegalStateException

Result partition information is not relevant to this stage b

Error message

Result partition information is not relevant to this stage because it does not shuffle

What it means

getResultPartitionBoundaries is only meaningful for stages that shuffle (cluster-by) their output. If the stage definition does not shuffle, partition boundaries never exist, so the tracker throws ISE explaining the information is irrelevant rather than returning a meaningless null/boundaries set.

Source

Thrown at multi-stage-query/src/main/java/org/apache/druid/msq/kernel/controller/ControllerStageTracker.java:253

  /**
   * Partitions for the results of the stage associated with this tracker.
   */
  ReadablePartitions getResultPartitions()
  {
    if (resultPartitions == null) {
      throw new ISE("Result partition information is not ready yet");
    } else {
      return resultPartitions;
    }
  }

  /**
   * @return Partition boundaries for the results of this stage
   */
  ClusterByPartitions getResultPartitionBoundaries()
  {
    if (!getStageDefinition().doesShuffle()) {
      throw new ISE("Result partition information is not relevant to this stage because it does not shuffle");
    } else if (resultPartitionBoundaries == null) {
      throw new ISE("Result partition information is not ready yet");
    } else {
      return resultPartitionBoundaries;
    }
  }


  /**
   * Get workers which need to be sent partition boundaries
   *
   * @return
   */
  IntSet getWorkersToSendPartitionBoundaries()
  {
    if (!getStageDefinition().doesShuffle()) {
      throw new ISE("Result partition information is not relevant to this stage because it does not shuffle");
    }

View on GitHub (pinned to 9b90983fd2)

Solutions

Guard the call with getStageDefinition().doesShuffle() and skip non-shuffling stages.
Use getResultPartitions() for non-shuffling stages when you only need the partition count.
If boundaries are needed for shuffle tuning, target the stage whose spec has a ClusterBy (the shuffle stage), typically not the final stage.

Example fix

// before
ClusterByPartitions b = tracker.getResultPartitionBoundaries();

// after
if (tracker.getStageDefinition().doesShuffle()) {
  ClusterByPartitions b = tracker.getResultPartitionBoundaries();
}

Defensive patterns

Strategy: type-guard

Validate before calling

if (!tracker.getStageDefinition().doesShuffle()) {
  return null; // boundaries are meaningless for non-shuffling stages
}

Type guard

ClusterByPartitions boundariesIfShuffling(ControllerStageTracker t) {
  return t.getStageDefinition().doesShuffle() ? t.getResultPartitionBoundaries() : null;
}

Try / catch

try {
  ClusterByPartitions b = tracker.getResultPartitionBoundaries();
} catch (IllegalStateException e) {
  if (e.getMessage().contains("does not shuffle")) {
    b = null; // expected for non-shuffling stages
  } else {
    throw e;
  }
}

Prevention

Gate boundary reads on StageDefinition.doesShuffle().
Identify the shuffle stage (ClusterBy spec) instead of iterating all stages blindly.
Use getResultPartitions() when only the partition count is needed.

When it happens

Trigger: Calling getResultPartitionBoundaries() on a ControllerStageTracker whose StageDefinition.doesShuffle() is false — e.g. final/result stages, non-shuffling leaf stages, or stages whose output channel mode is MEMORY without clustering.

Common situations: Controller or extension code iterating all stages of a query and calling getResultPartitionBoundaries unconditionally; debugging partition boundaries for an ingestion's final stage; misidentifying which stage performs the sort/cluster step.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

AI-assisted analysis of apache/druid@9b90983fd2 (2026-09-07). Data as JSON: /api/errors/f045d7106bfe7c21. Report an issue: GitHub.