elastic/elasticsearch · warning · TaskCancelledException
cancelled
Error message
cancelled
What it means
Thrown as a TaskCancelledException inside AutoDateHistogramAggregator's bucket-remapping tight loop when AggregationContext.isCancelled() returns true. The auto_date_histogram re-rounds buckets in a long-running inner loop that bypasses the standard per-document cancellation checks, so it polls cancellation explicitly. This is normal operational behavior, not a bug — it propagates task cancellation (client cancel, timeout, node drop).
Source
Thrown at modules/aggregations/src/main/java/org/elasticsearch/aggregations/bucket/histogram/AutoDateHistogramAggregator.java:587
return newRounding;
}
private void rebucket() {
rebucketCount++;
LongKeyedBucketOrds oldOrds = bucketOrds;
boolean success = false;
try {
long[] mergeMap = new long[Math.toIntExact(oldOrds.size())];
bucketOrds = new LongKeyedBucketOrds.FromMany(bigArrays());
success = true;
long maxOwning = oldOrds.maxOwningBucketOrd();
for (long owningBucketOrd = 0; owningBucketOrd <= maxOwning; owningBucketOrd++) {
/*
* Check for cancelation during this tight loop as it can take a while and the standard
* cancelation checks don't run during the loop. Becuase it's a tight loop.
*/
if (context.isCancelled()) {
throw new TaskCancelledException("cancelled");
}
LongKeyedBucketOrds.BucketOrdsEnum ordsEnum = oldOrds.ordsEnum(owningBucketOrd);
Rounding.Prepared preparedRounding = preparedRoundings[roundingIndexFor(owningBucketOrd)];
while (ordsEnum.next()) {
long oldKey = ordsEnum.value();
long newKey = preparedRounding.round(oldKey);
long newBucketOrd = bucketOrds.add(owningBucketOrd, newKey);
mergeMap[(int) ordsEnum.ord()] = newBucketOrd >= 0 ? newBucketOrd : -1 - newBucketOrd;
}
liveBucketCountUnderestimate = bigArrays().grow(liveBucketCountUnderestimate, owningBucketOrd + 1);
liveBucketCountUnderestimate.set(owningBucketOrd, Math.toIntExact(bucketOrds.bucketsInOrd(owningBucketOrd)));
}
merge(mergeMap, bucketOrds.size());
} finally {
if (success) {
oldOrds.close();
}
}View on GitHub (pinned to db6a809a66)
Solutions
- Treat this as expected: catch TaskCancelledException in task-aware code and report the search as cancelled, not failed.
- Reduce the workload (narrow time range, lower bucket count) so re-rounding completes within the cancellation window.
- If cancellations are unexpected, investigate why the task was cancelled (client disconnects, timeouts, resource pressure).
- Do not retry automatically without addressing the underlying cost — the cancellation was likely intentional.
Defensive patterns
Strategy: try-catch
Try / catch
try { /* execute search with auto_date_histogram */ }
catch (org.elasticsearch.tasks.TaskCancelledException e) {
// report as cancelled, not failed; do not blind-retry
} Prevention
- Treat TaskCancelledException as expected for long aggregations.
- Size aggregations to complete within typical cancellation windows.
- Investigate unexpected cancellations (timeouts, disconnects) before retrying.
When it happens
Trigger: A search containing an auto_date_histogram aggregation whose task is cancelled while it is in the re-rounding phase. Triggered by: client task cancellation API, search timeout (search.terminate_after / timeouts), shard relocation/failure, or node-level search cancellation.
Common situations: Long-running auto_date_histogram queries over large time ranges cancelled by users. Dashboards with auto-refresh where the user navigates away. Timeouts configured on the search. Heavy aggregation workload where the task manager reaps long tasks.
Related errors
- minimum_interval must be one of [{ALLOWED_INTERVALS.values()
- buckets must be greater than 0 for [{name}]
- buckets must be less than {bucketCeiling}
- dateTimeUnit must be one of {ALLOWED_INTERVALS.keySet()}
- [${name}] is missing : filters parameter
AI-assisted analysis of elastic/elasticsearch@db6a809a66 (2026-08-12).
Data as JSON: /api/errors/3a6440f0ab2fead1.
Report an issue: GitHub.