This node was started with paxos variant {}. SERIAL (and LOC

Error message

This node was started with paxos variant {}. SERIAL (and LOCAL_SERIAL) reads coordinated by this node will not offer linearizability (see CASSANDRA-12126 for details on what this means) with respect to other SERIAL operations. Please note that with this variant, SERIAL reads will be slower than QUORUM reads, yet offer no additional guarantees. This flag should only be used in the restricted case of upgrading from a pre-CASSANDRA-12126 version, and only if you understand the tradeoff.

What it means

CASSANDRA-12126 introduced Paxos variants that make SERIAL (LWT) reads truly linearizable. If the node is started with the legacy/unsafe Paxos variant (paxos_variant set to a non-linearizable value like v1), coordinator SERIAL/LOCAL_SERIAL reads offer no stronger guarantee than QUORUM reads while being slower. This warning fires once at startup in StorageProxy.initServer to make the tradeoff explicit.

Source

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

            EndpointsForToken selected = targets.contacts().withoutSelf();
            Replicas.temporaryAssertFull(selected); // TODO CASSANDRA-14548
            counterWriteTask(mutation, targets.withContacts(selected), responseHandler, localDataCenter, requestTime).run();
        };

        counterWriteOnCoordinatorPerformer = (mutation, targets, responseHandler, localDataCenter, requestTime) ->
        {
            EndpointsForToken selected = targets.contacts().withoutSelf();
            Replicas.temporaryAssertFull(selected); // TODO CASSANDRA-14548
            Stage.COUNTER_MUTATION.executor()
                                  .execute(counterWriteTask(mutation, targets.withContacts(selected), responseHandler, localDataCenter, requestTime));
        };


        ReadRepairMetrics.init();

        if (!Paxos.isLinearizable())
        {
            logger.warn("This node was started with paxos variant {}. SERIAL (and LOCAL_SERIAL) reads coordinated by this node " +
                        "will not offer linearizability (see CASSANDRA-12126 for details on what this means) with " +
                        "respect to other SERIAL operations. Please note that with this variant, SERIAL reads will be " +
                        "slower than QUORUM reads, yet offer no additional guarantees. This flag should only be used in " +
                        "the restricted case of upgrading from a pre-CASSANDRA-12126 version, and only if you " +
                        "understand the tradeoff.", Paxos.getPaxosVariant());
        }
    }

    /**
     * Apply @param updates if and only if the current values in the row for @param key
     * match the provided @param conditions.  The algorithm is "raw" Paxos: that is, Paxos
     * minus leader election -- any node in the cluster may propose changes for any row,
     * which (that is, the row) is the unit of values being proposed, not single columns.
     *
     * The Paxos cohort is only the replicas for the given key, not the entire cluster.
     * So we expect performance to be reasonable, but CAS is still intended to be used
     * "when you really need it," not for all your updates.
     *

View on GitHub (pinned to 88fd0f6a0e)

Solutions

Set paxos_variant to the linearizable default (remove the override so the default applies) and rolling-restart nodes
If it must stay during an upgrade, confirm all clients understand SERIAL reads give no extra guarantee, then remove after upgrade
Audit all nodes: values must be consistent cluster-wide to avoid mixed linearizability semantics

Example fix

// before (cassandra.yaml)
paxos_variant: v1

// after
# remove the line entirely (defaults to linearizable variant), then rolling restart
# paxos_variant:

Defensive patterns

Strategy: validation

Validate before calling

if (!Paxos.isLinearizable())
    throw new IllegalStateException("paxos_variant is non-linearizable; SERIAL reads offer no extra guarantee. Remove paxos_variant override from cassandra.yaml.");

Prevention

Never override paxos_variant unless mid-upgrade from pre-CASSANDRA-12126
Keep cassandra.yaml minimal; diff against the shipped default on upgrades
Audit cluster-wide config consistency with a config-drift tool

When it happens

Trigger: Node started with cassandra.yaml paxos_variant (or system property) set to a non-linearizable variant (e.g. 'v1'), detected in StorageProxy when Paxos.isLinearizable() returns false during init.

Common situations: Clusters still migrating from pre-3.0 behavior; operators copying old cassandra.yaml forward; temporarily set during rolling upgrade from a pre-CASSANDRA-12126 version and never reverted.

Understand the failure class

Background: "Invalid value" and "allowed values are" config errors: what your library rejected and how to fix it — this error's family across 41 libraries.

Related errors

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