Like most users, I deal with query related parse error messages quite regularly. One thing that has annoyed me for ages is how unreadable these messages are and I was wondering if it would be possible to improve this. Especially with large complicated queries this would be enormously helpful for many users, I imagine.
For reference below is an example. The only problem with this query is that I deliberately changed query into querie to trigger a validation error.
The message basically tells me that each of my shards failed to parse it. Unless you are running some weird mix of different es versions in one cluster, the parse error is going to be pretty much always identical across shards. So, repeating it is just clutter in this case. The escaped input makes things hard to read in any case and the fact that the actual problem is listed after this makes it hard to figure out what the problem is.
More helpful would if SearchParseException would return a proper json message that would be embedded in the aggregate SearchPhaseExecutionException with a separate field for the original input. Or if that is hard, it would be nice if the message would at least mention the problem before listing the content at least. Also, the from and size attrubute seems to be -1 here. This is probably because the json is actually well formed and there is no syntax problem to report from jackson.
{
"error": "SearchPhaseExecutionException[Failed to execute phase [query], all shards failed; shardFailures {[XtMbDAz6TBqSKZAUL5zfhA][inbot_users_v20][3]: SearchParseException[[inbot_users_v20][3]: from[-1],size[-1]: Parse Failure [Failed to parse source [{\n \"querie\": {\n \"term\": {\n \"user_id\": {\n \"value\": \"QA0vNmxMevzGf8HCMh8y4A\"\n }\n }\n }\n}\n]]]; nested: SearchParseException[[inbot_users_v20][3]: from[-1],size[-1]: Parse Failure [No parser for element [querie]]]; }{[XtMbDAz6TBqSKZAUL5zfhA][inbot_users_v20][2]: SearchParseException[[inbot_users_v20][2]: from[-1],size[-1]: Parse Failure [Failed to parse source [{\n \"querie\": {\n \"term\": {\n \"user_id\": {\n \"value\": \"QA0vNmxMevzGf8HCMh8y4A\"\n }\n }\n }\n}\n]]]; nested: SearchParseException[[inbot_users_v20][2]: from[-1],size[-1]: Parse Failure [No parser for element [querie]]]; }{[XtMbDAz6TBqSKZAUL5zfhA][inbot_users_v20][1]: SearchParseException[[inbot_users_v20][1]: from[-1],size[-1]: Parse Failure [Failed to parse source [{\n \"querie\": {\n \"term\": {\n \"user_id\": {\n \"value\": \"QA0vNmxMevzGf8HCMh8y4A\"\n }\n }\n }\n}\n]]]; nested: SearchParseException[[inbot_users_v20][1]: from[-1],size[-1]: Parse Failure [No parser for element [querie]]]; }{[XtMbDAz6TBqSKZAUL5zfhA][inbot_users_v20][0]: SearchParseException[[inbot_users_v20][0]: from[-1],size[-1]: Parse Failure [Failed to parse source [{\n \"querie\": {\n \"term\": {\n \"user_id\": {\n \"value\": \"QA0vNmxMevzGf8HCMh8y4A\"\n }\n }\n }\n}\n]]]; nested: SearchParseException[[inbot_users_v20][0]: from[-1],size[-1]: Parse Failure [No parser for element [querie]]]; }{[XtMbDAz6TBqSKZAUL5zfhA][inbot_users_v20][4]: SearchParseException[[inbot_users_v20][4]: from[-1],size[-1]: Parse Failure [Failed to parse source [{\n \"querie\": {\n \"term\": {\n \"user_id\": {\n \"value\": \"QA0vNmxMevzGf8HCMh8y4A\"\n }\n }\n }\n}\n]]]; nested: SearchParseException[[inbot_users_v20][4]: from[-1],size[-1]: Parse Failure [No parser for element [querie]]]; }]",
"status": 400
}
Like most users, I deal with query related parse error messages quite regularly. One thing that has annoyed me for ages is how unreadable these messages are and I was wondering if it would be possible to improve this. Especially with large complicated queries this would be enormously helpful for many users, I imagine.
For reference below is an example. The only problem with this query is that I deliberately changed query into querie to trigger a validation error.
The message basically tells me that each of my shards failed to parse it. Unless you are running some weird mix of different es versions in one cluster, the parse error is going to be pretty much always identical across shards. So, repeating it is just clutter in this case. The escaped input makes things hard to read in any case and the fact that the actual problem is listed after this makes it hard to figure out what the problem is.
More helpful would if SearchParseException would return a proper json message that would be embedded in the aggregate SearchPhaseExecutionException with a separate field for the original input. Or if that is hard, it would be nice if the message would at least mention the problem before listing the content at least. Also, the from and size attrubute seems to be -1 here. This is probably because the json is actually well formed and there is no syntax problem to report from jackson.