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
- Remove the GROUP BY clause from the in-transaction SELECT
- Fetch raw rows in the transaction and group/aggregate client-side
- 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
- Never wrap analytical/aggregating queries in transactions
- Aggregate in the application after reading raw rows
- Add CQL linter rules for transaction blocks
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
- No ORDER BY clause allowed within a transaction; %s statemen
- Transaction Statement is unsupported when migrating away fro
- Within a transaction, SELECT statements must select a single
- Transaction contains multiple updates to the same key and fi
- Accord transactions are disabled on table (See transactional
AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10).
Data as JSON: /api/errors/47e298510f1e808d.
Report an issue: GitHub.