apache/druid · error · IllegalStateException

Unknown tuningConfig type: [%s], Must be in [%s, %s, %s]

Error message

Unknown tuningConfig type: [%s], Must be in [%s, %s, %s]

What it means

CompactionTask.getTuningConfig only understands three tuningConfig implementations: CompactionTuningConfig, ParallelIndexTuningConfig, and IndexTuningConfig. Any other class (or null-typed custom/unknown impl) triggers this ISE, since the task cannot map it to an index-task tuning config.

Source

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

          indexTuningConfig.getPushTimeout(),
          indexTuningConfig.getSegmentWriteOutMediumFactory(),
          null,
          null,
          null,
          null,
          null,
          null,
          null,
          null,
          indexTuningConfig.isLogParseExceptions(),
          indexTuningConfig.getMaxParseExceptions(),
          indexTuningConfig.getMaxSavedParseExceptions(),
          indexTuningConfig.getMaxColumnsToMerge(),
          indexTuningConfig.getAwaitSegmentAvailabilityTimeoutMillis(),
          indexTuningConfig.getNumPersistThreads()
      );
    } else {
      throw new ISE(
          "Unknown tuningConfig type: [%s], Must be in [%s, %s, %s]",
          tuningConfig.getClass().getName(),
          CompactionTuningConfig.class.getName(),
          ParallelIndexTuningConfig.class.getName(),
          IndexTuningConfig.class.getName()
      );
    }
  }

  @VisibleForTesting
  public CurrentSubTaskHolder getCurrentSubTaskHolder()
  {
    return currentSubTaskHolder;
  }

  @JsonProperty
  public CompactionIOConfig getIoConfig()
  {

View on GitHub (pinned to 9b90983fd2)

Solutions

1. Set tuningConfig.type to one of: compaction, index_parallel, or index (the types mapping to the three accepted classes).
2. Replace a custom TuningConfig with CompactionTuningConfig for the compaction task.
3. If deserialization produced the wrong class, check the "type" discriminator in the JSON and registered Jackson subtypes.

Example fix

// before
"tuningConfig": { "type": "hadoop", ... }
// after
"tuningConfig": { "type": "compaction", "maxRowsInMemory": 1000000 }

final String t = tuningConfig == null ? null : tuningConfig.getClass().getName();
final boolean ok = t == null || t.equals("org.apache.druid.indexing.common.task.batch.parallel.ParallelIndexTuningConfig")
    || t.equals("org.apache.druid.indexing.common.task.CompactionTuningConfig")
    || t.equals("org.apache.druid.indexing.common.task.IndexTuningConfig");

try { task.getTuningConfig(); } catch (ISE e) { if (e.getMessage().startsWith("Unknown tuningConfig type")) { fix spec 'type' discriminator; } else throw e; }

When it happens

Trigger: Passing a tuningConfig of an unexpected type into CompactionTask — e.g., a custom TuningConfig subclass, a TuningConfig deserialized as a generic/unknown type due to a missing or wrong "type" field, or a type from a different task family.

Common situations: Hand-written compaction specs where "tuningConfig":{"type":...} uses an unsupported type name; copying tuningConfig from a non-compaction task; plugin/extension classpath changes making deserialization fall back to a default type.

Related errors

• Cannot deserialize type[%s] to an RoaringBitmap64Counter:
• Expected a number or an instance of MergingDigest, but recei
• Object is not of a type that can be deserialized to a quanti
• Object is not of a type that can be deserialized to a KllFlo
• Object is not of a type that can be deserialized to a quanti

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