apache/cassandra · warning · QueryCancelledException
QueryCancelledException
Error message
QueryCancelledException
What it means
ReadCommand's ClientRequest / execution controller checks an approximate-time deadline; if the command has been aborted (e.g. request timeout elapsed or a client disconnected and abort() was called), the iterator is stopped and QueryCancelledException is thrown. It converts an externally requested cancellation into a distinct, catchable failure instead of returning partial results.
Source
Thrown at src/java/org/apache/cassandra/db/ReadCommand.java:892
maybeCancel();
return row;
}
private void maybeCancel()
{
/*
* The value returned by approxTime.now() is updated only every
* {@link org.apache.cassandra.utils.MonotonicClock.SampledClock.CHECK_INTERVAL_MS}, by default 2 millis.
* Since MonitorableImpl relies on approxTime, we don't need to check unless the approximate time has elapsed.
*/
if (lastCheckedAt == approxTime.now())
return;
lastCheckedAt = approxTime.now();
if (isAborted())
{
stop();
throw new QueryCancelledException(ReadCommand.this);
}
}
}
private UnfilteredPartitionIterator withQueryCancellation(UnfilteredPartitionIterator iter)
{
return Transformation.apply(iter, new QueryCancellationChecker());
}
/**
* A transformation used for simulating slow queries by tests.
*/
@VisibleForTesting
private static class DelayInjector extends Transformation<UnfilteredRowIterator>
{
@Override
protected UnfilteredRowIterator applyToPartition(UnfilteredRowIterator partition)
{View on GitHub (pinned to 88fd0f6a0e)
Solutions
- Increase the client-side read/request timeout or reduce query size (LIMIT, paging).
- Retry with exponential backoff if the query was cancelled due to overload; investigate underlying read latency.
- Address root causes: run compaction, check tombstone counts, avoid unbounded queries.
- Ensure driver consistency: don't close sessions/cluster while queries are pending.
Example fix
// before clusterBuilder.withSocketOptions(opts.setReadTimeoutMillis(2000)); // too low for scans // after clusterBuilder.withSocketOptions(opts.setReadTimeoutMillis(20000)); // plus paged queries with LIMIT
Defensive patterns
Strategy: retry
Validate before calling
// Set driver read timeout comfortably above p99 query latency measured in monitoring.
Try / catch
try { rs = session.execute(query); } catch (DriverException e) {
if (isCancellation(e)) { if (attempt < MAX_RETRY) retryWithBackoff(); else fail(); } else throw e;
} Prevention
- Keep queries under the client read timeout: page, limit, index.
- Never close sessions/cluster while queries are in flight.
- Investigate read-latency regressions (compaction, GC, tombstones) promptly.
- Use idempotent queries so retries are safe.
When it happens
Trigger: A read that exceeds the client's request timeout (driver/socket read timeout) or whose client disconnects, so the coordinator aborts the command; the next iterator advance notices isAborted() and throws.
Common situations: Slow reads (huge scans, tombstone storms) exceeding the driver's read timeout; application shutting down/cancelling futures while a query is in flight; load-shedding under overload.
Understand the failure class
Background: Request timed out: what client-side request timeouts mean across libraries (Request timed out, TIMED_OUT, APITimeoutError) — this error's family across 39 libraries.
Related errors
- ${executor.name} not terminated
- TombstoneOverwhelmingException
- LocalReadSizeTooLargeException
- QueryCancelledException(readCommand)
- Command '${command}' took too long (${execTime}ms >= ${quota
AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10).
Data as JSON: /api/errors/f272209e423dd6b5.
Report an issue: GitHub.