redis/jedis · error · UnsupportedAggregationException

DEFAULT policy requires List, Set, Map, JedisByteHashMap…

Error message

DEFAULT policy requires List, Set, Map, JedisByteHashMap, or JedisByteMap types, but got: ${sample.getClass().getName()}

What it means

DefaultPolicyAggregator implements aggregation for commands using the DEFAULT response policy, which supports merging container types: List, Set, Map, JedisByteHashMap, or JedisByteMap. When the first reply sample is none of these types it throws UnsupportedAggregationException with the actual class name. Scalar replies cannot be merged under the DEFAULT policy.

Solutions

Use a response policy appropriate for scalar replies (e.g. FIRST/SUCCESS-ON-ANY) instead of DEFAULT for scalar-returning commands.
If merging is intended, ensure the Builder parses replies into List/Set/Map (e.g. BuilderFactory.STRING_LIST, MAP) so the DEFAULT aggregator can merge them.
For byte-map commands, make sure replies are built as JedisByteHashMap/JedisByteMap rather than plain values.

Example fix

// before
new CommandObject<>(args, BuilderFactory.STRING)           // scalar under DEFAULT policy
// after
new CommandObject<>(args, BuilderFactory.STRING_LIST)      // mergeable container

Defensive patterns

Strategy: validation

Validate before calling

// verify the Builder yields a mergeable container before using the DEFAULT policy
Object sample = jedis.sendCommand(cmd);
if (!(sample instanceof List || sample instanceof Set || sample instanceof Map)) {
  throw new IllegalStateException("DEFAULT policy needs a container reply, got " + sample.getClass());
}

Type guard

boolean isMergeableReply(Object r) {
  return r instanceof List || r instanceof Set || r instanceof Map;
}

Try / catch

try {
  return broadcastDefault();
} catch (UnsupportedAggregationException e) {
  logger.error("scalar reply under DEFAULT policy: {}", e.getMessage());
  throw new IllegalStateException(e);
}

Prevention

Use container Builders (STRING_LIST, STRING_MAP, etc.) with the DEFAULT policy
Use FIRST/success policies for scalar replies
Test broadcast commands against all shard reply shapes

When it happens

Trigger: Broadcasting a command marked with the DEFAULT response policy whose replies are scalars — e.g. a broadcast PING/SET whose reply is a String, STATUS, or Long instead of a collection.

Common situations: Applying multi-shard broadcast to commands returning single values (CONFIG GET with a scalar builder, DBSIZE returning Long handled by wrong policy), or custom commands where the declared Builder doesn't produce a container type.

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 redis/jedis@6dac31d4c2 (2026-09-08). Data as JSON: /api/errors/87e4d6207bba312d. Report an issue: GitHub.

Appendix: source

Thrown at src/main/java/redis/clients/jedis/executors/aggregators/DefaultPolicyAggregator.java:64

    }

    if (sample instanceof Set) {
      return (Aggregator<T, T>) new SetAggregator<>();
    }

    if (sample instanceof JedisByteHashMap) {
      return (Aggregator<T, T>) new JedisByteHashMapAggregator();
    }

    if (sample instanceof JedisByteMap) {
      return (Aggregator<T, T>) new JedisByteMapAggregator<>();
    }

    if (sample instanceof Map) {
      return (Aggregator<T, T>) new MapAggregator<>();
    }

    throw new UnsupportedAggregationException(
        "DEFAULT policy requires List, Set, Map, JedisByteHashMap, or JedisByteMap types, but got: "
            + sample.getClass().getName());
  }
}

View on GitHub (pinned to 6dac31d4c2)