apache/cassandra · error · InvalidRequestException

No GROUP BY clause allowed within a transaction; %s statemen

Error message

No GROUP BY clause allowed within a transaction; %s statement %s

What it means

SELECT statements with a GROUP BY clause are not allowed inside Accord transactions. Transactional reads do not support aggregation grouping, so TransactionStatement.validate(SelectStatement.RawStatement) throws when select.parameters.groups is non-empty.

Source

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

    @Override
    public AuditLogContext getAuditLogContext()
    {
        return new AuditLogContext(AuditLogEntryType.TRANSACTION);
    }

    @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);
    }

View on GitHub (pinned to 88fd0f6a0e)

Solutions

  1. Remove the GROUP BY clause from the in-transaction SELECT
  2. Fetch raw rows in the transaction and group/aggregate client-side
  3. Run the aggregating query outside the transaction

Example fix

// before
BEGIN TRANSACTION
  SELECT k, count(v) FROM t WHERE pk = 1 GROUP BY k;
COMMIT TRANSACTION;
// after
BEGIN TRANSACTION
  SELECT k, v FROM t WHERE pk = 1;
COMMIT TRANSACTION; // aggregate in application
Defensive patterns

Strategy: validation

Validate before calling

if (query.toUpperCase().matches("(?s).*GROUP\\s+BY.*") && inTransaction) throw new IllegalArgumentException("GROUP BY not allowed in transaction");

Try / catch

try { session.execute(txnCql); } catch (InvalidRequestException e) { if (e.getMessage().contains("No GROUP BY clause allowed within a transaction")) { /* remove GROUP BY, aggregate client-side */ } else throw e; }

Prevention

When it happens

Trigger: A SELECT within BEGIN TRANSACTION ... COMMIT on an Accord-enabled table contains `GROUP BY <column>`; detected alongside the ORDER BY check in the raw-statement validate path.

Common situations: Wrapping analytical/aggregating queries in a transaction to get consistent reads; auto-generated CQL that always emits GROUP BY.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors


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