Elasticsearch: Range query should tell you it doesn't support more than one field if you send two fields

[nik9000]

Reported here:

bool: {
    must: [
        {
            range: {
                price: [
                    {
                        gte: "200"
                    },
                    {
                        lt: "600"
                    }
                ],
                insert_date: [
                    {
                        gte: "2016-09-13 05:01:14"
                    }
                ]
            }
        }
    ]
}

responds with this error:

Fatal error: Uncaught Elasticsearch\Common\Exceptions\BadRequest400Exception: {"error":{"root_cause":[{"type":"parse_exception","reason":"failed to parse date field [600] with format [yyyy-MM-dd HH:mm:ss]"}],"type":"search_phase_execution_exception","reason":"all shards failed","phase":"init_scan","grouped":true,"failed_shards":[{"shard":0,"index":"data_standard_13_6_nl_test","node":"w115E6KmTiuBeW7RmJ_feQ","reason":{"type":"parse_exception","reason":"failed to parse date field [600] with format [yyyy-MM-dd HH:mm:ss]","caused_by":{"type":"illegal_argument_exception","reason":"Invalid format: \"600\" is too short"}}}]},"status":400}

But it really should say something about not supporting two fields.

I'm unsure of the affected version.

[erikvanderschaaf]

ElasticSearch version is 2.3.1

[nik9000]

Thanks @erikvanderschaaf! I've attached that label which will give us a starting place.

[jimczi]

This is fixed in master:
https://github.com/javanna/elasticsearch/commit/6d90a87f5461e19e1bb3a74883c2db87dcca0c07

... though there are more issues than just two fields in the range query in this example. I don't understand how we ended up with the parse exception about date field.

[nik9000]

It is probably worth adding a test case around the date vs number stuff, but, yeah, if this is fixed in the master/5.0/5.x branches I'm ok closing this as "already fixed, not yet released."

[javanna]

I confirm that I fixed this type of error with range and some other queries with similar problems, but I did that in master only. We could backport but most of the parsing code has changed in master and we have good unit tests for queries, while in 2.4 we only have integration tests. Not sure it is worth the effort to backport.

[nik9000]

Not sure it is worth the effort to backport.

I don't think so, not at this point.

[nik9000]

@javanna already fixed this but I pushed a test case that mimics @erikvanderschaaf's issue to master (7888dbfb313cc3ef95e7250173e52a3599228a1b) just to be super sure we don't break it again one day.