What causes "UNSAFE_MIXED_MUTATIONS_MSG" in apache/cassandra?

Split the request: send Accord transactional mutations and regular mutations in separate batches/requests.

apache/cassandra · error · InvalidRequestException

UNSAFE_MIXED_MUTATIONS_MSG

Error message

UNSAFE_MIXED_MUTATIONS_MSG

What it means

When mutations that use the (Accord) transactional time source are mixed with regular mutations in the same request, and cassandraaccord's mixed-time-source handling is set to 'log' or 'reject', Cassandra warns the client (ClientWarn) and logs; if handling is 'reject' it also throws InvalidRequestException with UNSAFE_MIXED_MUTATIONS_MSG. Mixing time sources is unsafe and can break ordering guarantees.

Source

Thrown at src/java/org/apache/cassandra/service/StorageProxy.java:1368

                Tracing.trace("{}", getStackTraceAsToString(t));
                throw t;
            }
            break;
        }
    }

    private static void checkMixedTimeSourceHandling()
    {
        AccordConfig.MixedTimeSourceHandling handling = DatabaseDescriptor.getAccord().mixedTimeSourceHandling;
        switch (handling)
        {
            case log:
            case reject:
            {
                ClientWarn.instance.warn(UNSAFE_MIXED_MUTATIONS_MSG);
                logger.warn(UNSAFE_MIXED_MUTATIONS_MSG);
                if (handling == AccordConfig.MixedTimeSourceHandling.reject)
                    throw new InvalidRequestException(UNSAFE_MIXED_MUTATIONS_MSG);
            }
            break;
            case ignore:
                // ignore
                break;
        }
    }

    private static ConsistencyLevel consistencyLevelForBatchLog(ConsistencyLevel consistencyLevel, boolean requireQuorumForRemove)
    {
        // If we are requiring quorum nodes for removal, we upgrade consistency level to QUORUM unless we already
        // require ALL, or EACH_QUORUM. This is so that *at least* QUORUM nodes see the update.
        ConsistencyLevel batchConsistencyLevel = requireQuorumForRemove
                                                 ? ConsistencyLevel.QUORUM
                                                 : consistencyLevel;

        switch (consistencyLevel)
        {

View on GitHub (pinned to 88fd0f6a0e)

Solutions

Split the request: send Accord transactional mutations and regular mutations in separate batches/requests.
Set MixedTimeSourceHandling to 'ignore' only if you understand the ordering implications (not recommended).
Migrate the remaining regular mutations in the mixed batch to Accord transactions.
Check ClientWarn.getWarnings() on the driver to catch the 'log' mode warning before it escalates.

Example fix

// before: mixed batch
BatchStatement b = new BatchStatement();
b.add(txnMutation); b.add(regularMutation);
session.execute(b);
// after: separate requests
session.execute(txnMutation);
session.execute(regularMutation);

Defensive patterns

Strategy: validation

Validate before calling

// split mixed batches before sending
if (batch.containsTxnMutations && batch.containsRegularMutations) {
    throw new IllegalArgumentException("mixed Accord/regular mutations are unsafe; split the batch");
}

Try / catch

try {
    session.execute(batch);
} catch (InvalidRequestException e) {
    if (e.getMessage().contains("time source")) {
        // resend as two separate single-type batches
    }
}
// also check warnings in 'log' mode
for (String w : session.getWarnings()) { /* look for mixed-mutations warning */ }

Prevention

Never mix Accord Txn mutations and regular mutations in one batch.
Review ClientWarn warnings during the Accord migration period.
Keep mixed_time_source_handling at 'reject' in production to fail fast.

When it happens

Trigger: A batch or request containing both Accord/Txn-aware mutations and plain mutations while AccordConfig.MixedTimeSourceHandling is log or reject (reject throws, log only warns).

Common situations: Applications partially migrated to Accord transactional writes still combining legacy mutations and Txn mutations in one batch; misconfigured cassandra_accord mixed_time_source_handling during experimentations.

Understand the failure class

Background: "Must be a positive integer", "Invalid value", "Unsupported": the invalid-argument-value error family, when a library rejects the value you pass — this error's family across 35 libraries.

Related errors

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