apache/druid · error · IllegalArgumentException
There is no format for type
Error message
There is no format for type %s
What it means
PeriodGranularity.getFormatter(Formatter) selects a DateTimeFormatter pattern based on the Formatter enum (DEFAULT, HIVE, LOWER_DEFAULT). The default branch throws IAE when a Formatter value has no corresponding case — an unhandled formatter type in this switch.
Solutions
- Pass one of the supported Formatter values: DEFAULT, HIVE, or LOWER_DEFAULT
- Upgrade Druid if you rely on a newer Formatter variant added in a later version
- Handle the new enum value explicitly in caller code before invoking getFormatter
Example fix
// before DateTimeFormatter fmt = granularity.getFormatter(myCustomFormatter); // after DateTimeFormatter fmt = granularity.getFormatter(Formatter.Type.DEFAULT); // supported value
Defensive patterns
Strategy: validation
Validate before calling
if (type != Formatter.Type.DEFAULT && type != Formatter.Type.HIVE && type != Formatter.Type.LOWER_DEFAULT) {
type = Formatter.Type.DEFAULT;
} Type guard
boolean isSupportedFormatter = type == Formatter.Type.DEFAULT || type == Formatter.Type.HIVE || type == Formatter.Type.LOWER_DEFAULT;
Try / catch
try { fmt = granularity.getFormatter(type); } catch (IllegalArgumentException e) { fmt = granularity.getFormatter(Formatter.Type.DEFAULT); } Prevention
- Pass only the enum values handled by getFormatter
- Pin Druid version if you rely on a specific Formatter enum surface
- Switch on Formatter in caller code rather than passing opaque values
When it happens
Trigger: Calling PeriodGranularity.getFormatter with a Formatter constant not covered by the switch (added enum variant or a caller passing a custom/new Formatter type).
Common situations: Code written against a newer Formatter enum than this Druid version supports; generic formatting utilities that pass through all enum values.
Understand the failure class
Background: Invalid enum value errors: "Unknown type", "Invalid scope", "must be one of" — when a string is not on the library's allowed list — this error's family across 23 libraries.
Related errors
- Expected key [ ] to be a Granularity, but got [ ]
- Granularity is not supported.
- Granularity [ ] is not supported
- Invalid segment granularity
- Period cannot be converted to milliseconds as some fields…
AI-assisted analysis of apache/druid@9b90983fd2 (2026-09-07).
Data as JSON: /api/errors/b81cd29e76d87736.
Report an issue: GitHub.
Appendix: source
Thrown at processing/src/main/java/org/apache/druid/java/util/common/granularity/PeriodGranularity.java:118
public DateTime getOrigin()
{
return hasOrigin ? DateTimes.utc(origin) : null;
}
// Used only for Segments. Not for Queries
@Override
public DateTimeFormatter getFormatter(Formatter type)
{
GranularityType granularityType = GranularityType.fromPeriod(period);
switch (type) {
case DEFAULT:
return DateTimeFormat.forPattern(granularityType.getDefaultFormat());
case HIVE:
return DateTimeFormat.forPattern(granularityType.getHiveFormat());
case LOWER_DEFAULT:
return DateTimeFormat.forPattern(granularityType.getLowerDefaultFormat());
default:
throw new IAE("There is no format for type %s", type);
}
}
@Override
public long bucketStart(long time)
{
return truncate(time);
}
@Override
public long increment(long t)
{
return chronology.add(period, t, 1);
}
@Override
public DateTime increment(DateTime time)
{View on GitHub (pinned to 9b90983fd2)