apache/druid · error · UOE

[%s] secondary partition type is not supported

Error message

[%s] secondary partition type is not supported

What it means

In IndexTask.generateAndPublishSegments, a switch over the partitionsSpec type handles HASH, LINEAR and a couple of variants; the default branch throws UOE stating the secondary partition type is not supported. This is the last line of defense against a partitionsSpec type the batch index task cannot allocate segments for.

Source

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

        );
        sequenceNameFunction = localSegmentAllocator.getSequenceNameFunction();
        segmentAllocator = localSegmentAllocator;
        break;
      case LINEAR:
        segmentAllocator = SegmentAllocators.forLinearPartitioning(
            toolbox,
            baseSequenceName,
            null,
            dataSchema,
            getTaskLockHelper(),
            getIngestionMode(),
            partitionAnalysis.getPartitionsSpec(),
            null
        );
        sequenceNameFunction = segmentAllocator.getSequenceNameFunction();
        break;
      default:
        throw new UOE("[%s] secondary partition type is not supported", partitionsSpec.getType());
    }

    final TransactionalSegmentPublisher publisher = buildSegmentPublisher(toolbox);

    String effectiveId = getContextValue(CompactionTask.CTX_KEY_APPENDERATOR_TRACKING_TASK_ID, null);
    if (effectiveId == null) {
      effectiveId = getId();
    }

    final Appenderator appenderator = BatchAppenderators.newAppenderator(
        effectiveId,
        toolbox.getAppenderatorsManager(),
        buildSegmentsSegmentGenerationMetrics,
        toolbox,
        dataSchema,
        tuningConfig,
        buildSegmentsMeters,
        buildSegmentsParseExceptionHandler

View on GitHub (pinned to 9b90983fd2)

Solutions

1. Use a supported partitionsSpec type (linear/hash) in tuningConfig
2. Check for typos or invalid values in the "type" field of partitionsSpec
3. Run range/dimension partitioning via compaction task or MSQ instead
4. Align spec-writing tooling with the Druid version of the overlord/task runner

Example fix

// before
"partitionsSpec": { "type": "single_dim", "targetRowsPerSegment": 5000000 }
// after
"partitionsSpec": { "type": "hash", "partitionDimensions": ["dim"], "numShards": 4 }

SecondaryPartitionType t = partitionsSpec.getType();
if (t != SecondaryPartitionType.LINEAR && t != SecondaryPartitionType.HASH) {
  throw new IllegalArgumentException("Secondary partition type not supported by IndexTask: " + t);
}

boolean allocatable(PartitionsSpec p) {
  return SecondaryPartitionType.LINEAR.equals(p.getType())
      || SecondaryPartitionType.HASH.equals(p.getType());
}

try {
  submitTask(spec);
} catch (UnsupportedOperationException e) {
  if (e.getMessage().endsWith("secondary partition type is not supported")) {
    spec.getTuningConfig().setPartitionsSpec(defaultHashSpec());
    submitTask(spec);
  } else throw e;
}

When it happens

Trigger: partitionsSpec.getType() reaching the segment-allocation switch with a value outside {LINEAR, HASH and the explicitly handled variants} — typically custom or newer partition types, or a corrupted/unparsed spec defaulting to an unexpected type.

Common situations: Submitting specs written for the MSQ or compaction engine to a classic IndexTask; plugin-provided partitioning strategies; Druid version skew between spec producer and task runner.

Related errors

• partitionsSpec[%s] is not supported
• %s
• %s cannot be used for perfect rollup
• ColumnCapacityExceededException
• Bloom filter aggregators are query-time only

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