What causes "Invalid operation (%s) for non counter column %s" in apache/cassandra?

Declare the column as counter type if atomic increments are needed (counter columns require a dedicated table design: no non-counter primary-key-other columns updates)

apache/cassandra · error · InvalidRequestException

Invalid operation (%s) for non counter column %s

Error message

Invalid operation (%s) for non counter column %s

What it means

Cassandra throws this during preparation when an increment operation (col = col + value) is issued against a non-counter column in a context where existing state cannot be read (counter-table semantics path, canReadExistingState=false). In that mode only CounterColumnType is legal; all other types are rejected.

Source

Thrown at src/java/org/apache/cassandra/cql3/Operation.java:347

            this.value = value;
        }

        public Operation prepare(TableMetadata metadata, ColumnMetadata receiver, boolean canReadExistingState) throws InvalidRequestException
        {
            if (!(receiver.type instanceof CollectionType))
            {
                if (receiver.type instanceof TupleType)
                    throw new InvalidRequestException(String.format("Invalid operation (%s) for tuple column %s", toString(receiver), receiver.name));

                if (canReadExistingState)
                {
                    if (!(receiver.type instanceof NumberType<?>) && !(receiver.type instanceof StringType))
                        throw new InvalidRequestException(String.format("Invalid operation (%s) for non-numeric and non-text type %s", toString(receiver), receiver.name));
                }
                else
                {
                    if (!(receiver.type instanceof CounterColumnType))
                        throw new InvalidRequestException(String.format("Invalid operation (%s) for non counter column %s", toString(receiver), receiver.name));
                }
                return new Constants.Adder(receiver, value.prepare(metadata.keyspace, receiver));
            }
            else if (!(receiver.type.isMultiCell()))
                throw new InvalidRequestException(String.format("Invalid operation (%s) for frozen collection column %s", toString(receiver), receiver.name));

            switch (((CollectionType<?>)receiver.type).kind)
            {
                case LIST:
                    return new Lists.Appender(receiver, value.prepare(metadata.keyspace, receiver));
                case SET:
                    return new Sets.Adder(receiver, value.prepare(metadata.keyspace, receiver));
                case MAP:
                    Term term;
                    try
                    {
                        term = value.prepare(metadata.keyspace, receiver);
                    }

View on GitHub (pinned to 88fd0f6a0e)

Solutions

Declare the column as counter type if atomic increments are needed (counter columns require a dedicated table design: no non-counter primary-key-other columns updates)
Otherwise use a regular numeric column and do read-then-write assignment
Migrate schema correctly: counters cannot be altered to/from other types; create a new column/table
Fix the query generator to emit increments only for counter columns

Example fix

// before (views int)
UPDATE stats SET views = views + 1 WHERE id = 1;  -- views is int, not counter
// after
UPDATE stats SET views = 43 WHERE id = 1;  -- read-modify-write, or make views counter

Defensive patterns

Strategy: validation

Validate before calling

AbstractType<?> t = tm.getColumn(col).getType();
if (!(t instanceof CounterColumnType))
    throw new IllegalArgumentException(col + " is not a counter; use read-then-write assignment");

Type guard

boolean isCounter(AbstractType<?> t) { return t instanceof CounterColumnType; }

Try / catch

try { session.execute(increment); } catch (InvalidRequestException e) { if (e.getMessage().contains("non counter column")) doReadModifyWrite(); else throw e; }

Prevention

Explicitly model counter columns; emit increments only for them
Remember counter columns need dedicated table design and cannot be ALTERed to other types
Review migrations that changed counter columns to scalars

When it happens

Trigger: Using 'UPDATE t SET mycol = mycol + 1' on a column that is not of type counter in a table where the adder requires counter semantics; e.g. incrementing an int column while relying on read-modify-write-free counter syntax.

Common situations: Developer confuses int/bigint columns with counter columns; counter tables (insert-not-allowed) where only CounterColumnType columns may use '+='; schema changed from counter to another numeric type, breaking existing update code.

Understand the failure class

Background: Type mismatch errors: IllegalArgumentException, TypeError and type guards across 150 open-source libraries — this error's family across 150 libraries.

Related errors

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