Description
We should strive to make error messages more actionable in case of parsing failures of a search request JSON. I know that pull parsing is making things harder here... Here are a few examples:
DELETE test
PUT test
GET test/_search
{
"query": {
"range": {
"date":
"gte": "2015-06-20",
"lte": "2015-09-22"
}
}
}
returns
{
"error" : {
"root_cause" : [
{
"type" : "parsing_exception",
"reason" : "[range] query does not support [date]",
"line" : 5,
"col" : 9
}
],
"type" : "parsing_exception",
"reason" : "[range] query does not support [date]",
"line" : 5,
"col" : 9
},
"status" : 400
}This is invalid JSON (notice the missing opening { after "date":, however the error message hints at the fact, that the range query has an issue.
Second example, valid JSON, but not parseable, as the "type" field is not within the multi match query
DELETE test
PUT test
GET test/_search
{
"query": {
"multi_match": {
"query": "party planning",
"fields": [
"headline",
"short_description"
]
},
"type": "phrase"
}
}
response
# GET test/_search
{
"error" : {
"root_cause" : [
{
"type" : "parsing_exception",
"reason" : "[multi_match] malformed query, expected [END_OBJECT] but found [FIELD_NAME]",
"line" : 10,
"col" : 5
}
],
"type" : "parsing_exception",
"reason" : "[multi_match] malformed query, expected [END_OBJECT] but found [FIELD_NAME]",
"line" : 10,
"col" : 5
},
"status" : 400
}While technically correct, that the multi_match query should end, this error message does help any user, who is not aware of how JSON is parsed. You could mention, that the JSON should be closed, but element "type" was found instead or something.
And the last candidate, valid JSON, but invalid querying
DELETE test
PUT test
{
"mappings": {
"properties": {
"my_field" : {
"type": "keyword"
}
}
}
}
GET test/_search
{
"size": 0,
"aggs": {
"transactions_by_8_hrs": {
"date_histogram": {
"field": "my_field",
"fixed_interval": "8h"
}
}
}
}
returns
# GET test/_search
{
"error" : {
"root_cause" : [
{
"type" : "illegal_argument_exception",
"reason" : "Field [my_field] of type [keyword] is not supported for aggregation [date_histogram]"
}
],
"type" : "search_phase_execution_exception",
"reason" : "all shards failed",
"phase" : "query",
"grouped" : true,
"failed_shards" : [
{
"shard" : 0,
"index" : "test",
"node" : "fZhL9ocFSr22NFU5D1G83A",
"reason" : {
"type" : "illegal_argument_exception",
"reason" : "Field [my_field] of type [keyword] is not supported for aggregation [date_histogram]"
}
}
],
"caused_by" : {
"type" : "illegal_argument_exception",
"reason" : "Field [my_field] of type [keyword] is not supported for aggregation [date_histogram]",
"caused_by" : {
"type" : "illegal_argument_exception",
"reason" : "Field [my_field] of type [keyword] is not supported for aggregation [date_histogram]"
}
}
},
"status" : 400
}The response is telling the user, that the field is not supported, but this is not actionable. How about returning what kind of fields are actually supported instead?