I'm getting a shard failure with Elasticsearch 2.3.3 due to a min aggregation being run on an inappropriate field however, the min aggregation is wrapped in a filter aggregation that I thought was supposed to avoid this.
Reproducible steps:
- create index1 containing type1:
POST http://elasticsearch:9200/index1
{"mappings" : {"type1" : {"properties" : {"field1" : {"type" : "string"}, "field2" : {"type" : "string"}}}}}
- create index2 containing type2:
POST http://elasticsearch:9200/index2
{"mappings" : {"type2" : {"properties" : {"field2" : {"type" : "date"}, "field3" : {"type" : "string"}}}}}
- index two documents:
POST http://elasticsearch:9200/_bulk
{"index" : {"_index": "index1", "_type" : "type1", "_id": "AVW13RC-KNxA0HG4GOkj"}}
{"field1": "value1", "field2": "value2"}
{"index" : {"_index": "index2", "_type" : "type2", "_id": "AVW13j8RKNxA0HG4GOkl"}}
{"field2": "2016-07-04", "field3": "value3"}
- perform the following search containing a filtered min aggregation on type2.field2:
POST http://elasticsearch:9200/index1,index2/_search
{
"query" : {"match_all" : {}},
"from" : 0, "size" : 0,
"aggs" : {
"type2_field2_min_filter" : {
"filter" : {"type" : {"value" : "type2"}},
"aggs" : {
"type2_field2_min" : {
"min" : {"field" : "field2"}
}
}
}
}
}
- Elasticsearch returns an unexpected shard failure:
{
"took" : 103,
"timed_out" : false,
"_shards" : {
"total" : 2,
"successful" : 1,
"failed" : 1,
"failures" : [
{
"shard" : 0, "index" : "index1", "node" : "qh4ZMdr2TUirveJ5hrpXuA",
"reason" : {
"type" : "illegal_argument_exception",
"reason" : "Expected numeric type on field [field2], but got [string]"
}
}
]
},
"hits" : {"total" : 1, "max_score" : 0.0, "hits" : []},
"aggregations" : {
"type2_field2_min_filter" : {
"doc_count" : 1,
"type2_field2_min" : {
"value" : 1.4675904E12,
"value_as_string" : "2016-07-04T00:00:00.000Z"
}
}
}
}
As you can see, the search is across both indices, however the filter aggregation is intended to limit the min aggregation to field2 of type2. Elasticsearch appears to run the min aggregation on field2 of type1 in index1 anyway, which results in a shard failure.
Is this an Elasticsearch bug or should I be adding logic to the calling code to ignore the shard failure in this case?