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
- Check the ValueType of the input signature; ensure only standard Druid value types (LONG, DOUBLE, STRING, arrays, COMPLEX) reach this method.
- Update Druid modules so the processing/ expression code matches the version that introduced the column type.
- If handling a custom complex type, wrap it as ValueType.COMPLEX with a complex type name rather than a new ValueType.
- 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
- Only feed standard Druid ValueTypes into the expression layer
- Keep all Druid modules on the same version
- Use COMPLEX with a type name rather than inventing new ValueTypes
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
- Unsupported expression type[%s]
- Unsupported unknown value type
- FLOAT types are not supported natively by Druid expressions
- Unsupported expression type[%s]
- Unknown type [%s]
AI-assisted analysis of apache/druid@9b90983fd2 (2026-09-07).
Data as JSON: /api/errors/c243eef1d200fb65.
Report an issue: GitHub.