Java Client breaks on parsing GetAliasesResponse when one alias does not exist

[EgbertW]

Elasticsearch Version

8.18.1

Installed Plugins

No response

Java Version

bundled

OS Version

docker image: elasticsearch/elasticsearch:8.18.1

Problem Description

When you use the _alias endpoint to resolve multiple aliases at once, the Java client breaks on parsing the response if one of them does not exist.

Expected behaviour:

GetAliasesResponse containing alias/index relations that do exist

Actual behaviour:

A TransportException is thrown and the existing aliases go unnoticed.

Steps to Reproduce

PUT /example-index
PUT /example-index/_alias/test

GET /_alias/test,test2

The response will look like this:

{
  "error": "alias [test2] missing",
  "status": 404,
  "example-index": {
    "aliases": {
      "test": {}
    }
  }
}

So this response tells us that test2 does not exist, and it also tells us that example-index has the alias test. However, the Java client breaks on this because the response has a HTTP 404 response, and error but also the regular payload. This leaves us with a TransportException rather than an ElasticsearchException, or, preferably, a GetAliasesResponse.

The cat/_aliases endpoint gives usable response with

GET /_cat/aliases/test,test2?format=json&h=index,alias

but the docs clearly state that that is not intended for software consumption.

Logs (if relevant)

co.elastic.clients.transport.TransportException: node: http://localhost:9201/, status: 404, [es/indices.get_alias] Failed to decode error response, check exception cause for additional details
	at co.elastic.clients.transport.ElasticsearchTransportBase.getApiResponse(ElasticsearchTransportBase.java:369)
	at co.elastic.clients.transport.ElasticsearchTransportBase.lambda$performRequestAsync$0(ElasticsearchTransportBase.java:205)
	at java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:934)
	at java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:911)
	at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510)
	at java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2179)
	at co.elastic.clients.transport.rest_client.RestClientHttpClient$1.onSuccess(RestClientHttpClient.java:116)
	at org.elasticsearch.client.RestClient$FailureTrackingResponseListener.onSuccess(RestClient.java:680)
	at org.elasticsearch.client.RestClient$1.completed(RestClient.java:403)
	at org.elasticsearch.client.RestClient$1.completed(RestClient.java:397)
	at org.apache.http.concurrent.BasicFuture.completed(BasicFuture.java:122)
	at org.apache.http.impl.nio.client.DefaultClientExchangeHandlerImpl.responseCompleted(DefaultClientExchangeHandlerImpl.java:182)
	at org.apache.http.nio.protocol.HttpAsyncRequestExecutor.processResponse(HttpAsyncRequestExecutor.java:448)
	at org.apache.http.nio.protocol.HttpAsyncRequestExecutor.inputReady(HttpAsyncRequestExecutor.java:338)
	at org.apache.http.impl.nio.DefaultNHttpClientConnection.consumeInput(DefaultNHttpClientConnection.java:265)
	at org.apache.http.impl.nio.client.InternalIODispatch.onInputReady(InternalIODispatch.java:87)
	at org.apache.http.impl.nio.client.InternalIODispatch.onInputReady(InternalIODispatch.java:40)
	at org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady(AbstractIODispatch.java:114)
	at org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:162)
	at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:337)
	at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:315)
	at org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:276)
	at org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:104)
	at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:591)
	at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: co.elastic.clients.json.UnexpectedJsonEventException: Unexpected JSON event 'START_OBJECT' instead of 'KEY_NAME'
	at co.elastic.clients.json.JsonpUtils.expectEvent(JsonpUtils.java:106)
	at co.elastic.clients.transport.endpoints.EndpointBase$1.deserialize(EndpointBase.java:150)
	at co.elastic.clients.transport.endpoints.EndpointBase$1.deserialize(EndpointBase.java:144)
	at co.elastic.clients.json.JsonpDeserializer.deserialize(JsonpDeserializer.java:77)
	at co.elastic.clients.transport.ElasticsearchTransportBase.getApiResponse(ElasticsearchTransportBase.java:355)
	... 24 more

[l-trotta]

Hello, thanks for reporting this! Unfortunately this is a known issue where some endpoints have a totally different structure for standard responses and error responses, and for strictly typed client it's complicated to parse. I'll look into this and see if the error fields can be added to the response fields!

[l-trotta]

also reported in #900