DateHistogramAggregation with Composite sub-aggregation


I got the following exception when trying to execute a DateHistogramAggregation with a sub-aggregation of type CompositeAggregation. Any reason why this wouldn't be supported? Also would this be supported with a regular HistogramAggregation? I am using Elasticsearch version 7.7.0. I was also surprised to not get an exception during client validation phase prior to the query actually being executed.


ElasticsearchException[Elasticsearch exception [type=search_phase_execution_exception, reason=all shards failed]]; nested: ElasticsearchException[Elasticsearch exception [type=illegal_argument_exception, reason=[composite] aggregation cannot be used with a parent aggregation of type: [DateHistogramAggregatorFactory]]]; nested: ElasticsearchException[Elasticsearch exception [type=illegal_argument_exception, reason=[composite] aggregation cannot be used with a parent aggregation of type: [DateHistogramAggregatorFactory]]];
	at org.elasticsearch.ElasticsearchException.innerFromXContent(
	at org.elasticsearch.ElasticsearchException.failureFromXContent(
	at org.elasticsearch.common.xcontent.AbstractObjectParser.lambda$declareObjectArray$7(
	at org.elasticsearch.common.xcontent.AbstractObjectParser.lambda$declareFieldArray$13(
	at org.elasticsearch.common.xcontent.AbstractObjectParser.parseArray(
	at org.elasticsearch.common.xcontent.AbstractObjectParser.lambda$declareFieldArray$14(
	at org.elasticsearch.common.xcontent.ObjectParser.lambda$declareField$4(
	at org.elasticsearch.common.xcontent.ObjectParser.parseValue(
	at org.elasticsearch.common.xcontent.ObjectParser.parseArray(
	at org.elasticsearch.common.xcontent.ObjectParser.parseSub(
	at org.elasticsearch.common.xcontent.ObjectParser.parse(
	at org.elasticsearch.common.xcontent.ConstructingObjectParser.parse(
	at org.elasticsearch.common.xcontent.ConstructingObjectParser.apply(
	at org.elasticsearch.client.RestHighLevelClient.parseEntity(
	at org.elasticsearch.client.RestHighLevelClient.lambda$performRequestAsyncAndParseEntity$10(
	at org.elasticsearch.client.RestHighLevelClient$1.onSuccess(
	at org.elasticsearch.client.RestClient$FailureTrackingResponseListener.onSuccess(
	at org.elasticsearch.client.RestClient$1.completed(
	at org.elasticsearch.client.RestClient$1.completed(
	at org.apache.http.concurrent.BasicFuture.completed(
	at org.apache.http.impl.nio.client.DefaultClientExchangeHandlerImpl.responseCompleted(
	at org.apache.http.nio.protocol.HttpAsyncRequestExecutor.processResponse(
	at org.apache.http.nio.protocol.HttpAsyncRequestExecutor.inputReady(
	at org.apache.http.impl.nio.DefaultNHttpClientConnection.consumeInput(
	at org.apache.http.impl.nio.client.InternalIODispatch.onInputReady(
	at org.apache.http.impl.nio.client.InternalIODispatch.onInputReady(
	at org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady(
	at org.apache.http.impl.nio.reactor.BaseIOReactor.readable(
	at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(
	at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(
	at org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(
	at org.apache.http.impl.nio.reactor.BaseIOReactor.execute(
	at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$
	at java.base/


can you describe your usecase and if possible provide a data example? There is probably an alternative to solve the problem. The purpose of a composite aggregation is to page through a larger dataset. I therefore wonder about using a composite aggregation as sub aggregation.

As for validation: This is by design, the client code only does simple validations but most validations are done server side.


Thanks for your response. My use case is to compute hourly metrics based on applications state. So each hour I want to know how many instances of a given application was executed broken by state. For instance:

Application A, Version 1.0, State: Successful, 10 instances
Application A, Version 1.0, State: Faulted, 2 Instances
Application B, Version 2.0, State: Successful, 3 instances
Application C, Version 1.0, State: Aborted, 2 Instances

I am guessing the alternative to using a composite aggregation as sub-aggregation to the top Date Histogram Aggregation would be to use several levels of sub term aggregations.


The most important usecase for composite aggregations is pagination, this allows you to retrieve all buckets even if you have a lot of buckets and therefore ordinary aggregations run into limits.

A composite aggregation can have several sources, so you can use a date_histogram and e.g. a terms source for the application:

            "composite" : {
                "sources" : [
                    { "date": { "date_histogram" : { "field": "timestamp", "fixed_interval": "1h" } } },
                    { "application": { "terms" : { "field": "app" } } }

Are you planning to store the results to e.g. further analyze it? Transform is build on top of composite aggs, made for usescases like yours. This saves custom code, is already build for robustness and scale (and there is a nice UI to get you started easily).


Thanks again. This makes sense. I didn't know I could use a date histogram as one of the sources for a composite aggregation. Also thanks for pointing out the Transform functionality.


This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.