apache/druid · error · UOE

partitionsSpec[%s] is not supported

Error message

partitionsSpec[%s] is not supported

What it means

IndexTask.isReady validates the tuningConfig's partitionsSpec type before acquiring locks. Only LINEAR and HASH secondary partitioning are supported by the batch index task; any other type produces this UOE (Unsupported Operation Exception) naming the partitionsSpec class. It fails early, before the task does any work.

Source

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

    this.ingestionSchema = ingestionSchema;
    this.ingestionState = IngestionState.NOT_STARTED;
    this.isStandAloneTask = isStandAloneTask;
  }

  @Override
  public String getType()
  {
    return TYPE;
  }

  @Override
  public boolean isReady(TaskActionClient taskActionClient) throws Exception
  {
    final IndexTuningConfig tuningConfig = getIngestionSchema().getTuningConfig();
    if (tuningConfig != null && tuningConfig.getPartitionsSpec() != null) {
      if (tuningConfig.getPartitionsSpec().getType() != SecondaryPartitionType.LINEAR
          && tuningConfig.getPartitionsSpec().getType() != SecondaryPartitionType.HASH) {
        throw new UOE("partitionsSpec[%s] is not supported", tuningConfig.getPartitionsSpec().getClass().getName());
      }
    }
    return determineLockGranularityAndTryLock(
        taskActionClient,
        ingestionSchema.dataSchema.getGranularitySpec().inputIntervals()
    );
  }

  @Override
  public boolean requireLockExistingSegments()
  {
    return isGuaranteedRollup(getIngestionMode(), ingestionSchema.tuningConfig)
           || (getIngestionMode() != IngestionMode.APPEND);
  }

  @Override
  public List<DataSegment> findSegmentsToLock(TaskActionClient taskActionClient, List<Interval> intervals)
      throws IOException

View on GitHub (pinned to 9b90983fd2)

Solutions

  1. Change partitionsSpec to type "linear" (dynamic) or "hash" in tuningConfig
  2. If range partitioning is required, use a compaction task or the MSQ engine instead of IndexTask
  3. Validate the tuningConfig with the JSON schema/spec parser before submitting
  4. Check the Druid version's supported partition types for batch ingestion

Example fix

// before
"partitionsSpec": { "type": "range" }
// after
"partitionsSpec": { "type": "hash", "numShards": 4, "partitionDimensions": [] }
Defensive patterns

Strategy: validation

Validate before calling

String type = tuningConfig.getPartitionsSpec().getType().name();
if (!type.equals("LINEAR") && !type.equals("HASH")) {
  throw new IllegalArgumentException("IndexTask supports only linear/hash, got: " + type);
}

Type guard

boolean isIndexTaskCompatible(PartitionsSpec p) {
  return p != null && (p.getType() == SecondaryPartitionType.LINEAR
      || p.getType() == SecondaryPartitionType.HASH);
}

Try / catch

try {
  ready = task.isReady(actionClient);
} catch (UnsupportedOperationException e) {
  log.error("Unsupported partitionsSpec for IndexTask: {}", e.getMessage());
  throw new IllegalArgumentException("Fix tuningConfig.partitionsSpec to linear or hash", e);
}

Prevention

When it happens

Trigger: Submitting an index task (or MSQ/batch-style spec handed to IndexTask) whose tuningConfig.partitionsSpec has a type other than LINEAR or HASH — e.g. SINGLE_DIM or a range/range-partitioning type from a different engine's spec.

Common situations: Copying a tuningConfig from a compaction task using range partitioning into a plain batch index task; hand-written specs using an unsupported partitionsSpec type; framework version mismatch where a new partitionsSpec type isn't supported by IndexTask.

Related errors

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