apache/cassandra · error · UnsupportedOperationException

Unsupported collection type:

Error message

Unsupported collection type: 

What it means

AccordSerializers.deserializeCqlCollectionAsTerm deserializes CQL collection values (SET, LIST, MAP) into Accord term MultiElements.Value. If the column's AbstractType is a collection of another kind, it throws UnsupportedOperationException 'Unsupported collection type: ' + type. Only set/list/map collection kinds are supported.

Source

Thrown at src/java/org/apache/cassandra/service/accord/serializers/AccordSerializers.java:73

public class AccordSerializers
{
    public static <A, B> EmbeddedAsymmetricVersionedSerializer<A, B, Version> embedded(Version version, AsymmetricVersionedSerializer<A, B, Version> serializer)
    {
        return new EmbeddedAsymmetricVersionedSerializer<>(version, Version.Serializer.instance, serializer);
    }

    public static Term.Terminal deserializeCqlCollectionAsTerm(ByteBuffer buffer, AbstractType<?> type)
    {
        CollectionType<?> collectionType = (CollectionType<?>) type;

        if (collectionType.kind == SET)
            return MultiElements.Value.fromSerialized(buffer, (SetType<?>) type);
        else if (collectionType.kind == LIST)
            return MultiElements.Value.fromSerialized(buffer, (ListType<?>) type);
        else if (collectionType.kind == MAP)
            return MultiElements.Value.fromSerialized(buffer, (MapType<?, ?>) type);

        throw new UnsupportedOperationException("Unsupported collection type: " + type);
    }

    public static final ParameterisedUnversionedSerializer<ColumnMetadata, TableMetadata> columnMetadataSerializer = new ParameterisedUnversionedSerializer<>()
    {
        @Override
        public void serialize(ColumnMetadata column, TableMetadata table, DataOutputPlus out) throws IOException
        {
            out.writeUnsignedVInt32(column.uniqueId);
        }

        @Override
        public ColumnMetadata deserialize(TableMetadata table, DataInputPlus in) throws IOException
        {
            return table.getColumnById(in.readUnsignedVInt32());
        }

        @Override
        public long serializedSize(ColumnMetadata column, TableMetadata table)

View on GitHub (pinned to 88fd0f6a0e)

Solutions

1. Change the column to a supported collection type (set, list, or map) or a scalar/frozen type the serializers handle.
2. Ensure all nodes run a version whose AccordSerializers understands the column's type (align versions / restart with consistent schema).
3. Re-check the table schema (DESCRIBE TABLE) for the offending column and alter it accordingly.

Example fix

// before
custom_tags tuple<int, text> -- non-supported collection-ish type
// after
ALTER TABLE t DROP custom_tags;
ALTER TABLE t ADD custom_tags map<int, text>;

AbstractType<?> t = column.type;
if (t.isCollection() && !t.isFrozen()) {
    switch (((CollectionType<?>) t).kind) {
        case SET: case LIST: case MAP: break;
        default: throw new IllegalArgumentException("unsupported collection kind for " + column.name);
    }
}

boolean isSupportedCollection(AbstractType<?> t) { return !t.isCollection() || ((CollectionType<?>) t).kind == SET || ((CollectionType<?>) t).kind == LIST || ((CollectionType<?>) t).kind == MAP; }

try { deserialize(...); } catch (UnsupportedOperationException e) { LOG.error("Unsupported column type; use set/list/map: {}", e.getMessage()); }

When it happens

Trigger: Deserializing an Accord-managed table column whose type reports a collection kind other than SET/LIST/MAP — e.g. a future/custom collection type or a misconfigured column type in a user table consumed by Accord serialization paths.

Common situations: Using exotic or custom column types in tables referenced by Accord-backed features; schema drift between nodes where one node sees a different type; forward-compatibility issues after a Cassandra upgrade introduces new collection kinds.

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

• Not enough bytes to read size of %dth field %s
• Not enough bytes to read %dth field %s
• Not enough bytes to read size of %dth component
• Not enough bytes to read %dth component
• Transaction Statement is unsupported when migrating away fro

AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10). Data as JSON: /api/errors/90ac8278b0c25f43. Report an issue: GitHub.