apache/cassandra · error · InvalidRequestException

Accord transactions are disabled on table (See transactional

Error message

Accord transactions are disabled on table (See transactional_mode in table options); %s statement %s

What it means

The target table of a SELECT in a transaction has transactional_mode not set to full (Accord disabled), so the statement cannot participate in an Accord transaction. TransactionStatement.validate(SelectStatement) checks prepared.table.isAccordEnabled() and rejects the SELECT.

Source

Thrown at src/java/org/apache/cassandra/cql3/statements/TransactionStatement.java:706

    @Override
    public boolean eligibleAsPreparedStatement()
    {
        // false is the default, but still best to be explicit.
        return false;
    }

    private static void validate(SelectStatement.RawStatement select)
    {
        if (select.parameters.orderings != null && !select.parameters.orderings.isEmpty())
            throw invalidRequest(NO_ORDER_BY_IN_TXNS_MESSAGE, "SELECT", select.source);
        if (select.parameters.groups != null && !select.parameters.groups.isEmpty())
            throw invalidRequest(NO_GROUP_BY_IN_TXNS_MESSAGE, "SELECT", select.source);
    }

    private static void validate(SelectStatement prepared)
    {
        if (!prepared.table.isAccordEnabled())
            throw invalidRequest(TRANSACTIONS_DISABLED_ON_TABLE_MESSAGE, "SELECT", prepared.source);
        if (prepared.table.params.pendingDrop)
            throw invalidRequest(TRANSACTIONS_DISABLED_ON_TABLE_BEING_DROPPED_MESSAGE, "SELECT", prepared.source);
        if (prepared.table.isCounter())
            throw invalidRequest(NO_COUNTERS_IN_TXNS_MESSAGE, "SELECT", prepared.source);
        if (prepared.hasAggregation())
            throw invalidRequest(NO_AGGREGATION_IN_TXNS_MESSAGE, "SELECT", prepared.source);

        // when "LIMIT ?" this check can't be performed, so need to do again once the options are known
        if (prepared.getRestrictions().keyIsInRelation())
            checkTrue(prepared.isLimitMarker() || prepared.getLimit(null) == DataLimits.NO_LIMIT, NO_PARTITION_IN_CLAUSE_WITH_LIMIT, "SELECT", prepared.source);
    }

    public static class Parsed extends QualifiedStatement.Composite
    {
        private final List<SelectStatement.RawStatement> assignments;
        private final SelectStatement.RawStatement select;
        private final List<RowDataReference.Raw> returning;
        private final List<ModificationStatement.Parsed> updates;

View on GitHub (pinned to 88fd0f6a0e)

Solutions

1. Enable Accord on the table: ALTER TABLE t WITH transactional_mode = 'full' (all replicas must be Accord-capable)
2. Remove the SELECT of that table from the transaction
3. Verify the table's current mode via DESCRIBE / schema metadata

Example fix

// before
CREATE TABLE t (...) WITH transactional_mode = 'off';
// after
ALTER TABLE t WITH transactional_mode = 'full';

KeyspaceMetadata ks = cluster.getMetadata().getKeyspace(keyspace); TableMetadata t = ks.getTable(table); if (!t.getOptions().getTransactionalMode().isFull()) throw new IllegalStateException("Accord disabled on " + table);

try { session.execute(txnCql); } catch (InvalidRequestException e) { if (e.getMessage().contains("Accord transactions are disabled on table")) { /* fall back to non-transactional path or ALTER table */ } else throw e; }

When it happens

Trigger: Executing any SELECT inside BEGIN TRANSACTION ... COMMIT against a table created/Altered with `transactional_mode = off` (or not set to full) in table options.

Common situations: Tables created before enabling Accord that were never migrated; setting transactional_mode to the wrong value or forgetting it in WITH options.

Related errors

• Transaction Statement is unsupported when migrating away fro
• No ORDER BY clause allowed within a transaction; %s statemen
• No GROUP BY clause allowed within a transaction; %s statemen
• Element selection not supported for column %s of type %s
• Invalid reference type %s (%s) for "%s" of type %s

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