[search_phase_execution_exception] without a root reason

Hello.

I’m using Elasticsearch 9.1.3, access with java client (no security, almost all setting but cluster name are default).

If to execute query_string query with wrong syntax like

GET test/_search

{

    "query": {

        "query_string": {

          "default_field": "description",

          "query": "\"test" /* no closing quote*/

        }

    }

} </>

using Kibana - I see detailed error message with description what exactly is wrong with query.

But when I run such query using Elasticsearch java client I see only top level exception in my app log, without cause (no information what is wront with query at all):

[es/search] failed: [search_phase_execution_exception] all shards failed

	at co.elastic.clients.transport.ElasticsearchTransportBase.getApiResponse(ElasticsearchTransportBase.java:372) ~[elasticsearch-java-9.1.3.jar:na]

	at co.elastic.clients.transport.ElasticsearchTransportBase.performRequest(ElasticsearchTransportBase.java:154) ~[elasticsearch-java-9.1.3.jar:na]

	at co.elastic.clients.elasticsearch.ElasticsearchClient.search(ElasticsearchClient.java:4824) ~[elasticsearch-java-9.1.3.jar:na]

Also I don’t see any message in elasticsearch logs.

Could you help with this issue, please?

Er …

Do a GET _cat/shards and see what it says.

Everything is fine with shards, read question please. I know where is the error, I don’t understand why java exception doesn’t contain information about it. I need it for further processing.

Hello!

“all shards failed” is the high level exception, if you need more detailed information you can take the ElasticsearchException and dig deeper, into responseerrorreason

Sorry. Welcome to the forum.

You want to send broken queries to elasticsearch from the java client and elasticsearch to tell you precisely how they are broken when responding, irrespective of the brokenness of your query? IMHO this is unrealistic. There are options to check a query before sending to elasticsearch - try POST index/_validate/query

Kibana is a UI, it’s expected to check things. Like say Excel will check if you put something daft in a cell.

I know this is top level exception, I can’t see reason when executing incorrect query using Elasticsearch Java client. I’ll try to explain again.

This result what I see in Kibana. You see, I have detailed description what is wrong (root_cause, failed_shards sections):

{

"error": {

"root_cause": [

{

"type": "query_shard_exception",

"reason": """Failed to parse query ["test]""",

"index_uuid": "ojQBM4MjSMmQ6lsa1eKgbQ",

"index": "test"

}

],

"type": "search_phase_execution_exception",

"reason": "all shards failed",

"phase": "query",

"grouped": true,

"failed_shards": [

{

"shard": 0,

"index": "test",

"node": "lb-VL2QoSgaO9iNxQSMfNw",

"reason": {

"type": "query_shard_exception",

"reason": """Failed to parse query ["test]""",

"index_uuid": "ojQBM4MjSMmQ6lsa1eKgbQ",

"index": "test",

"caused_by": {

"type": "parse_exception",

"reason": """Cannot parse '"test': Lexical error at line 1, column 6.  Encountered:  after prefix "\"test" (in lexical state 2)""",

"caused_by": {

"type": "token_mgr_error",

"reason": """Lexical error at line 1, column 6.  Encountered:  after prefix "\"test" (in lexical state 2)"""

}

}

}

}

]

},

"status": 400

}

In Java application I see only:

co.elastic.clients.elasticsearch._types.ElasticsearchException: [es/search] failed: [search_phase_execution_exception] all shards failed

	at co.elastic.clients.transport.ElasticsearchTransportBase.getApiResponse(ElasticsearchTransportBase.java:372) ~[elasticsearch-java-9.1.3.jar:na]

	at co.elastic.clients.transport.ElasticsearchTransportBase.performRequest(ElasticsearchTransportBase.java:154) ~[elasticsearch-java-9.1.3.jar:na]

	at co.elastic.clients.elasticsearch.ElasticsearchClient.search(ElasticsearchClient.java:4824) ~[elasticsearch-java-9.1.3.jar:na]
....
//all other stack trace elements are my project classes or Spring-Boot related

This is how it worked in 6.4.2. I saw Java exception with exact cause.

I’m trying to move to recent Elasticsearch version and faced this problem

Correct, this is what will be logged by default, if the exception is not handled. By catching the ElasticsearchException you can customize the depth of error you can log, for example:

public static void main(String[] args) throws IOException {

        try (
            ElasticsearchClient client = ElasticsearchClient.of(e -> e
                .host("host")
                .apiKey("apikey"))) {

            client.search(s -> s
                .index("test")
                .query(q -> q
                    .queryString(qs -> qs
                        .query("\"test")))
            );
        } catch (ElasticsearchException e) {
            System.out.println(e.error());
        }
    }

will print:

ErrorCause: {"phase":"query","failed_shards":[{"shard":0,"index":"test","node":"uLsAhJL1SG6fVTHEDpVP7w","reason":{"type":"query_shard_exception","reason":"Failed to parse query [\"test]","index_uuid":"7FHHQQkBREG2GsOemvrlyw","index":"test","caused_by":{"type":"parse_exception","reason":"Cannot parse '\"test': Lexical error at line 1, column 6.  Encountered: <EOF> after prefix \"\\\"test\" (in lexical state 2)","caused_by":{"type":"token_mgr_error","reason":"Lexical error at line 1, column 6.  Encountered: <EOF> after prefix \"\\\"test\" (in lexical state 2)"}}}}],"grouped":true,"type":"search_phase_execution_exception","reason":"all shards failed","root_cause":[{"index_uuid":"7FHHQQkBREG2GsOemvrlyw","index":"test","type":"query_shard_exception","reason":"Failed to parse query [\"test]"}]}

which is the same thing you’d see in Kibana :slight_smile:

I got it, thank to ltrotta ). I just need to fetch ErrorCause like on the snippet below and read exception cause. Thank you!

} catch (Exception e) {

        	ElasticsearchException es_e = (ElasticsearchException) e;

        	ErrorCause ec = es_e.error();

The reason why it behaves differently from version 6.x of the old Java client is that the new Java client tries to match more closely what the server outputs, including nested exceptions. We’ve been debating overriding specifically “all shards failed” with the underlying exception, since the high level exception does not really help.

In 6.4.2 it was “caused by“ series of top level exception, simple as it.

In 9.1.3 I need to examine specific fields in ElasticsearchException class. And it kinda unobvious ).