apache/cassandra · error · InvalidRequestException

Partition key of additional mutation does not match primary…

Error message

Partition key of additional mutation does not match primary update key

What it means

For single-partition requests augmented by triggers, every PartitionUpdate generated by the trigger must target the same partition key as the primary update. validateSamePartition throws this InvalidRequestException when the trigger's update partition key differs from the original statement's key, since mixing partitions would break the atomicity guarantees of a single-partition write.

Solutions

Fix the trigger to emit updates only for the same partition key as the incoming mutation
Move the cross-partition write out of the trigger into application logic
If cross-partition writes are required, execute them via a separate statement/batch instead of the trigger

Example fix

// before (trigger code)
PartitionUpdate other = PartitionUpdate.builder(otherTable, differentKey).build();
// after
PartitionUpdate same = PartitionUpdate.builder(otherTable, sameKeyAsPrimary).build();

Defensive patterns

Strategy: validation

Validate before calling

// inside trigger: assert key equality before returning
assert update.partitionKey().equals(primaryKey) : 'trigger update key mismatch';

Try / catch

catch InvalidRequestException mentioning 'Partition key of additional mutation' and disable the trigger

Prevention

Derive trigger update keys from the statement's key, never independently
Test triggers with real statement keys
Avoid computing decorated keys manually in trigger code

When it happens

Trigger: A trigger returns an augmented Mutation whose PartitionUpdate.partitionKey() does not equal the DecoratedKey of the row being modified in the original statement.

Common situations: Triggers computing derived keys (e.g. writing to an aggregate/index table under a different key); buggy trigger logic hashing or serializing the key differently; triggers designed for multi-partition batch usage attached to single-row statements.

Understand the failure class

Background: Schema validation failed / invalid input schema: payload rejected because its shape doesn't match the expected schema — this error's family across 28 libraries.

Related errors

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

Appendix: source

Thrown at src/java/org/apache/cassandra/triggers/TriggerExecutor.java:216

        }

        ArrayList<PartitionUpdate> updates = new ArrayList<>(tmutations.size());
        for (Mutation mutation : tmutations)
        {
            for (PartitionUpdate update : mutation.getPartitionUpdates())
            {
                validateSamePartition(tableId, key, update);
                updates.add(update);
            }
        }
        return updates;
    }

    private void validateSamePartition(TableId tableId, DecoratedKey key, PartitionUpdate update)
    throws InvalidRequestException
    {
        if (!key.equals(update.partitionKey()))
            throw new InvalidRequestException("Partition key of additional mutation does not match primary update key");

        if (!tableId.equals(update.metadata().id))
            throw new InvalidRequestException("table of additional mutation does not match primary update table");
    }

    private void validate(Collection<Mutation> tmutations) throws InvalidRequestException
    {
        for (Mutation mutation : tmutations)
        {
            QueryProcessor.validateKey(mutation.key().getKey());
            for (PartitionUpdate update : mutation.getPartitionUpdates())
                update.validate();
        }
    }

    /**
     * Switch class loader before using the triggers for the column family, if
     * not loaded them with the custom class loader.

View on GitHub (pinned to 88fd0f6a0e)