apache/cassandra · warning

Mutations look to have different time sources, some are usin

Error message

Mutations look to have different time sources, some are using 'USING TIMESTAMP' and others are using the server timestamp; writes to the Accord table will not be linearizable while using transactions.  To allow this behavior set accord.mixed_time_source_handling=log or ignore

What it means

Accord transactions require all mutations in a write to use a consistent time source. Mixing mutations that carry an explicit 'USING TIMESTAMP' with mutations using the server-assigned timestamp breaks linearizability guarantees. When accord.mixed_time_source_handling is 'log', the warning is issued both to the client (ClientWarn) and the server log; when 'reject', it also throws InvalidRequestException. This index is the ClientWarn.instance.warn(...) emission.

Source

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

            catch (Exception t)
            {
                // Unexpected error so it would be helpful to have details
                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;

View on GitHub (pinned to 88fd0f6a0e)

Solutions

1. Make all mutations in Accord transactions use the same time source — drop USING TIMESTAMP so server timestamps apply
2. Alternatively supply explicit timestamps for every mutation in the transaction
3. If intentionally accepting the risk, set accord.mixed_time_source_handling: ignore in cassandra.yaml
4. If reject is desired for safety, keep the setting but fix the offending client code to pass validation

Example fix

// before
BEGIN TRANSACTION
  INSERT INTO t (k,v) VALUES (1,1) USING TIMESTAMP 12345;
  UPDATE t SET v=2 WHERE k=2;
COMMIT TRANSACTION

// after
BEGIN TRANSACTION
  INSERT INTO t (k,v) VALUES (1,1);
  UPDATE t SET v=2 WHERE k=2;
COMMIT TRANSACTION

// client-side: ensure all statements in an Accord transaction omit USING TIMESTAMP
for (Statement st : transactionStatements) {
    if (st.getTimestamp() != null)
        throw new IllegalArgumentException("USING TIMESTAMP not allowed in Accord transaction: " + st);
}

When it happens

Trigger: An Accord transaction batch contains some mutations with client-supplied timestamps (USING TIMESTAMP) and some with default server timestamps, while DatabaseDescriptor.getAccord().mixedTimeSourceHandling is log or reject.

Common situations: Application code partially migrated to Accord transactions where some statements still use USING TIMESTAMP; ORMs or drivers injecting timestamps inconsistently; default config where the operator never set mixed_time_source_handling.

Understand the failure class

Background: Conflicting config options: "cannot be used together" — configuration validation errors across open-source libraries — this error's family across 162 libraries.

Related errors

• Transaction Statement is unsupported when migrating away fro
• UNSAFE_MIXED_MUTATIONS_MSG
• Accord transaction uses dropped tables
• Timeout waiting to exeute waiting transactions
• No serializer exists for kind {kind}

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