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

  1. Treat this as expected: catch TaskCancelledException in task-aware code and report the search as cancelled, not failed.
  2. Reduce the workload (narrow time range, lower bucket count) so re-rounding completes within the cancellation window.
  3. If cancellations are unexpected, investigate why the task was cancelled (client disconnects, timeouts, resource pressure).
  4. 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

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


AI-assisted analysis of elastic/elasticsearch@db6a809a66 (2026-08-12). Data as JSON: /api/errors/3a6440f0ab2fead1. Report an issue: GitHub.