apache/druid · error · ISE

%s is not supported for partitionsSpec[%s]

Error message

%s is not supported for partitionsSpec[%s]

What it means

OverlordCoordinatingSegmentAllocator only knows how to derive partial shard specs for certain partitionsSpec types; for any other (unknown/new) partitionsSpec it throws ISE naming the allocator and spec class. This is a defensive check that unsupported partitioning strategies aren't silently mishandled in range-based (non-dynamic) ingestion.

Source

Thrown at indexing-service/src/main/java/org/apache/druid/indexing/common/task/OverlordCoordinatingSegmentAllocator.java:134

    if (partitionsSpec.getType() == SecondaryPartitionType.LINEAR) {
      if (taskLockHelper.isUseSegmentLock()) {
        if (taskLockHelper.hasOverwritingRootGenerationPartition(interval) && (ingestionMode
                                                                               != AbstractTask.IngestionMode.APPEND)) {
          final OverwritingRootGenerationPartitions overwritingRootGenerationPartitions = taskLockHelper
              .getOverwritingRootGenerationPartition(interval);
          if (overwritingRootGenerationPartitions == null) {
            throw new ISE("Can't find overwritingSegmentMeta for interval[%s]", interval);
          }
          return new NumberedOverwritePartialShardSpec(
              overwritingRootGenerationPartitions.getStartRootPartitionId(),
              overwritingRootGenerationPartitions.getEndRootPartitionId(),
              overwritingRootGenerationPartitions.getMinorVersionForNewSegments()
          );
        }
      }
      return NumberedPartialShardSpec.instance();
    } else {
      throw new ISE(
          "%s is not supported for partitionsSpec[%s]",
          OverlordCoordinatingSegmentAllocator.class.getName(),
          partitionsSpec.getClass().getName()
      );
    }
  }

  @Override
  public SequenceNameFunction getSequenceNameFunction()
  {
    return sequenceNameFunction;
  }
}

View on GitHub (pinned to 9b90983fd2)

Solutions

  1. Use a supported partitionsSpec (e.g. SingleDimensionPartitionsSpec or HashedPartitionsSpec as accepted by the range-based path) for this ingestion
  2. If a new partitionsSpec type was added, extend OverlordCoordinatingSegmentAllocator.createPartialShardSpec to handle it
  3. Check the Druid version for known bugs where the wrong partitionsSpec is wired into MSQ/parallel ingestion
Defensive patterns

Strategy: type-guard

Validate before calling

if (!(partitionsSpec instanceof SingleDimensionPartitionsSpec)
    && !(partitionsSpec instanceof HashedPartitionsSpec)) {
  throw new IllegalArgumentException(partitionsSpec.getType() + " unsupported for range-based allocation");
}

Type guard

boolean isSupportedPartitionsSpec(PartitionsSpec p) {
  return p instanceof SingleDimensionPartitionsSpec || p instanceof HashedPartitionsSpec;
}

Try / catch

try { allocator.partialShardSpec(...); } catch (ISE e) { if (e.getMessage().contains("is not supported for partitionsSpec")) { fallbackToCompatibleAllocator(); } else { throw e; } }

Prevention

When it happens

Trigger: Creating an OverlordCoordinatingSegmentAllocator with a partitionsSpec it doesn't support (e.g. a new/custom PartitionsSpec type, or DynamicPartitionsSpec passed where range-based allocation is expected) and then calling partialShardSpec.

Common situations: Adding a new PartitionsSpec implementation without updating the allocator; specs crafted by hand with mismatched partitionsSpec vs the coordinator's supported set; internal calls after a Druid version upgrade changing spec classes.

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/eb42303633c19829. Report an issue: GitHub.