apache/druid · error · ISE

Unsupported value type[%s]

Error message

Unsupported value type[%s]

What it means

fromColumnTypeStrict() exhaustively maps known column value types (LONG, FLOAT/DOUBLE, STRING, ARRAY, COMPLEX) to ExpressionTypes; any ValueType that falls through the switch — i.e. a type outside the supported set — triggers this IllegalStateException. It indicates the column type system has produced a value type the expression layer cannot represent.

Source

Thrown at processing/src/main/java/org/apache/druid/math/expr/ExpressionType.java:152

        return STRING;
      case ARRAY:
        switch (valueType.getElementType().getType()) {
          case LONG:
            return LONG_ARRAY;
          case FLOAT:
          case DOUBLE:
            return DOUBLE_ARRAY;
          case STRING:
            return STRING_ARRAY;
          case ARRAY:
          case COMPLEX:
            break;
        }
        return ExpressionTypeFactory.getInstance().ofArray(fromColumnTypeStrict(valueType.getElementType()));
      case COMPLEX:
        return ExpressionTypeFactory.getInstance().ofComplex(valueType.getComplexTypeName());
      default:
        throw new ISE("Unsupported value type[%s]", valueType);
    }
  }


  /**
   * The expression system does not distinguish between {@link ValueType#FLOAT} and {@link ValueType#DOUBLE}, so this
   * method will convert {@link ValueType#FLOAT} to {@link #DOUBLE}.
   */
  @Nullable
  public static ExpressionType fromColumnType(@Nullable TypeSignature<ValueType> valueType)
  {
    if (valueType == null) {
      return null;
    }
    switch (valueType.getType()) {
      case LONG:
        return LONG;
      case FLOAT:

View on GitHub (pinned to 9b90983fd2)

Solutions

  1. Check the ValueType of the input signature; ensure only standard Druid value types (LONG, DOUBLE, STRING, arrays, COMPLEX) reach this method.
  2. Update Druid modules so the processing/ expression code matches the version that introduced the column type.
  3. If handling a custom complex type, wrap it as ValueType.COMPLEX with a complex type name rather than a new ValueType.
  4. Catch IllegalStateException and log the offending valueType to diagnose which type leaked in.
Defensive patterns

Strategy: type-guard

Validate before calling

switch (valueType.getType()) {
  case LONG: case FLOAT: case DOUBLE: case STRING: case ARRAY: case COMPLEX: break;
  default: throw new IllegalArgumentException("Unhandled type before conversion: " + valueType);
}

Type guard

boolean isConvertible(ValueType t) {
  return t == ValueType.LONG || t == ValueType.FLOAT || t == ValueType.DOUBLE
      || t == ValueType.STRING || t == ValueType.ARRAY || t == ValueType.COMPLEX;
}

Try / catch

try {
  ExpressionType t = ExpressionType.fromColumnTypeStrict(sig);
} catch (IllegalStateException e) {
  log.error("Unsupported value type: %s", sig); throw e;
}

Prevention

When it happens

Trigger: Passing a TypeSignature<ValueType> whose getType() is not LONG/FLOAT/DOUBLE/STRING/ARRAY/COMPLEX — typically only possible when a custom or unrecognized ValueType reaches the expression layer via fromColumnTypeStrict.

Common situations: Custom segment/column type extensions introducing new ValueTypes not understood by the expression engine; version mismatches where a newer column type is fed to an older expression module; internal bugs constructing malformed type signatures.

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