Hi,
I'm trying to migrate from using the org.elasticsearch.client.RestClient to co.elastic.clients.elasticsearch.ElasticsearchClient. However, I'm noticing one difference in behavior. The ElasticsearchClient has bespoke handling for http error status codes 400, 401, 403, 404 and 405. With RestClient these error code would result in the RestClient throwing an exception. With ElasticsearchClient it, by design, ignores these error and just returns the response with some status field. This change in behavior means that all client code needs to updated everywhere with respect to error handling. Is there some background to understand this change or a way to preserve the existing behavior from the RestClient when migrating to ElasticsearchClient?
RestClient and ElasticsearchClient are very different.
RestClient is a thin layer on top of the Apache httpclient libraries that handles things like retries on the different nodes on a cluster. But it works with http requests and responses whose bodies are just byte arrays.
ElasticsearchClient is a so-called "high level client" that exposes all Elasticsearch API endpoints as methods with strongly-typed classes and objects to represent the request and response bodies. This is why it has a custom handling of errors, since the interpretation of errors can vary depending on the API endpoint that is called.
It to be noted also that ElasticsearchClient is implemented on top on RestClient.
@swallez I am aware of all that you mention. But the question remains: Is it possible to use ElasticsearchClient and not have it ignore http status codes 400, 401, 403, 404 and 405? We have adopters and want them to maintain the same error handling approach they already have.
Sorry, I don't understand what you're trying to achieve. What are those adopters (or adapters?) and what is their purpose?
@swallez Sorry, let me elaborate a little. We provide an abstraction for our developers on top of the Elasticsearch APIs. Currently this abstraction uses the RestClient internally. Our adopters user our abstraction and not aware that the implementation uses RestClient. We were considering changing our implementation to use ElasticsearchClient instead of RestClient - this would have to be transparent to our adopters. But the difference between RestClient and ElasticsearchClient in how they handle certain http status codes means that is not possible - unless there is someway to configure the ElasticseachClient to not specify that the ignore parameters? See code here.
Also it's not clear to me why the highlevel client choose to ignore these http status codes as errors?
Ok, I see what you mean. The "ignore" name is misleading. It tells RestClient to return the http response for these status codes instead of throwing an exception.
We do that because those status codes are handled at a higher level in RestClientTransport (see code): it's the endpoint object's responsibility to decide if a given status code has to be considered as an error or not.
Most of the time anything different from 200 will then be reported as an error and result in an ElasticsearchException, but not always. Some API endpoints such as "document exists" return a boolean value. A 200 will be true and a 404 will be false and will not result in an exception.
it's the endpoint object's responsibility to decide if a given status code has to be considered as an error or not
Can you give an example where one endpoint treats it as an error and other does not? I would still like to know if it's possible to keep the same error handling logic when switching from RestClient to ElasticsearchClient
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.