Aggregations: ClassCastException when sibling aggregations have the same name

[colings86]

If I run a search query of the following kind:

curl -XGET 'http://localhost:9200/index/_search?pretty' -d '{ "query" : { "match_all" : {} }, "aggs" : { "agg1" : { "terms" : { "field" : "stringField" } }, "agg1" : { "terms" : { "field" : "longField" } } } }'

It causes a ClassCastException in Elasticsearch:

{
  "error" : "ClassCastException[org.elasticsearch.search.aggregations.bucket.terms.LongTerms$Bucket cannot be cast to org.elasticsearch.search.aggregations.bucket.terms.StringTerms$Bucket]",
  "status" : 500
}

It looks like it is actually combining all aggregations with the same name into one combined aggregation. The error occurs when the fields in the two aggregations are different types but will also give strange results when they are both the same type. I have so far only tried this with the Terms aggregation but I suspect it will be an issue for other types too.

There should probably be some validation of sibling aggregations to ensure they have unique names and throw back a parse error to the client if there are multiple sibling aggregations with the same name.

More than this, since aggregations can be referenced from other aggregations by name, should aggregations names be unique across all aggregations and not just within their siblings?

[jpountz]

There should probably be some validation of sibling aggregations to ensure they have unique names and throw back a parse error to the client if there are multiple sibling aggregations with the same name.

+1 I'll work on that

[jpountz]

More than this, since aggregations can be referenced from other aggregations by name, should aggregations names be unique across all aggregations and not just within their siblings?

When referring to another aggregation (eg. for sorting the buckets of a terms aggregation), you need to specify the relative path from the current aggregation to the one that is used for sorting, so there should be no ambiguity. Or were you thinking about something else?

[colings86]

No, that is what I was thinking of, so its just a problem for sibling aggregations then