You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using the Java client, calls to our cluster for a non-existent document throw a JsonParseException (note that upon further investigation, this is likely due to some additional wrappers our system uses that substitute unformatted text for the JSON---still, handling 404s and providing a more foolproof error-catching seem like they may be good practice).
How can one reproduce the bug?
Use the OpenSearch client to perform a get request on a document that doesn't exist in the cluster.
What is the expected behavior?
Response contains actionable information (e.g. status of 404, type of HttpNotFoundException, etc.). Likely, throw a new TransportException like it does for 403 or 401 statuses.
if (statusCode == HttpStatus.SC_FORBIDDEN) {
throw new TransportException("Forbidden access", new ResponseException(clientResp));
} else if (statusCode == HttpStatus.SC_UNAUTHORIZED) {
throw new TransportException("Unauthorized access", new ResponseException(clientResp));
Notably, the final attempt to decode the error response only catches MissingRequiredPropertyException, so if there are other Json parsing issues of the entity.Content, they are not handled by throw new TransportException("Failed to decode error response", new ResponseException(clientResp));
Seems that this code should probably:
Explicitly handle 404s, similar to how it handles other 4xx statuses.
More generally catch errors at the bottom of the attempts to decode so that JsonParsingExceptions/other exceptions aren't thrown
What is your host/environment?
MacOS 14.7, Java 17, OpenSearch Client 2.11
The text was updated successfully, but these errors were encountered:
What is the bug?
When using the Java client, calls to our cluster for a non-existent document throw a JsonParseException (note that upon further investigation, this is likely due to some additional wrappers our system uses that substitute unformatted text for the JSON---still, handling 404s and providing a more foolproof error-catching seem like they may be good practice).
How can one reproduce the bug?
Use the OpenSearch client to perform a get request on a document that doesn't exist in the cluster.
What is the expected behavior?
Response contains actionable information (e.g. status of 404, type of HttpNotFoundException, etc.). Likely, throw a new TransportException like it does for 403 or 401 statuses.
Notably, the final attempt to decode the error response only catches MissingRequiredPropertyException, so if there are other Json parsing issues of the entity.Content, they are not handled by
throw new TransportException("Failed to decode error response", new ResponseException(clientResp));
Seems that this code should probably:
What is your host/environment?
MacOS 14.7, Java 17, OpenSearch Client 2.11
The text was updated successfully, but these errors were encountered: