apache/druid · error · UnsupportedOperationException

This method should not be invoked for this granularity type

Error message

This method should not be invoked for this granularity type

What it means

AllGranularity represents 'all time' as a single infinite bucket, so it has no meaningful path-based DateTimeFormatter. Calling getFormatter() throws UnsupportedOperationException('This method should not be invoked for this granularity type'). It guards against silently producing wrong date parsing/formatting for path-derived timestamps.

Source

Thrown at processing/src/main/java/org/apache/druid/java/util/common/granularity/AllGranularity.java:44

import org.joda.time.format.DateTimeFormatter;

/**
 * AllGranularty buckets everything into a single bucket
 */
public class AllGranularity extends Granularity
{
  /**
   * This constructor is public b/c it is serialized and deserialized
   * based on type in GranularityModule
   */
  public AllGranularity()
  {
  }

  @Override
  public DateTimeFormatter getFormatter(Formatter type)
  {
    throw new UnsupportedOperationException("This method should not be invoked for this granularity type");
  }

  @Override
  public long increment(long time)
  {
    return DateTimes.MAX.getMillis();
  }

  @Override
  public DateTime increment(DateTime time)
  {
    return DateTimes.MAX;
  }

  @Override
  public long bucketStart(long time)
  {
    return DateTimes.MIN.getMillis();

View on GitHub (pinned to 9b90983fd2)

Solutions

Use a real granularity (e.g. 'day', 'hour') in your ingestion/path spec when path-based date extraction is needed
Branch on granularity instanceof AllGranularity (or GranularityType.ALL) and skip formatter-based parsing
Check your GranularitySpec/segment granularity configuration; ALL is only valid when the whole dataset is one bucket
Upgrade Druid if this comes from an internal component — newer versions may special-case ALL

Example fix

// before
DateTimeFormatter fmt = granularity.getFormatter(Formatter.DEFAULT);
// after
if (granularity instanceof AllGranularity) {
  // no path-derived timestamp for ALL granularity; use query interval instead
} else {
  DateTimeFormatter fmt = granularity.getFormatter(Formatter.DEFAULT);
}

Defensive patterns

Strategy: type-guard

Validate before calling

if (granularity instanceof AllGranularity) {
  throw new IllegalArgumentException("Path-based date extraction requires a bucketed granularity, not ALL");
}

Type guard

boolean supportsPathFormatting(Granularity g) {
  return !(g instanceof AllGranularity) && !(g instanceof DurationGranularity);
}

Try / catch

try {
  formatter = granularity.getFormatter(type);
} catch (UnsupportedOperationException e) {
  // granularity (e.g. ALL) has no path formatter; use explicit timestamp/interval instead
}

Prevention

Never combine granularity ALL with path-based timestamp extraction in specs
Special-case ALL/Duration granularities in generic Granularity-dispatch code
Validate GranularitySpec granularity type when path parsers are configured
Prefer PeriodGranularity for ingestion requiring path-derived intervals

When it happens

Trigger: Calling AllGranularity.getFormatter(type), typically from code that extracts dates from file paths or segments based on the segment/granularity type without special-casing ALL granularity.

Common situations: Batch ingestion from paths (e.g. static/hdfs/Drtfy path parsers) configured with granularity 'all'; generic code that iterates Granularity types and assumes every granularity supports path formatting; misconfigured GranularitySpec using ALL where a bucketed granularity is required.

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