-
Notifications
You must be signed in to change notification settings - Fork 190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] Throw OpenSearchException on 409 Conflict #749
Comments
+1, it's pretty common to want the entire underlying HTTP request/response to be accessible. The alternative of exposing methods is also fine if we want to support a generic way to retrieve various non-transport-specific things like HTTP status codes. |
i can provide a PR which just makes |
@rursprung I don't know what's best. Do you have an opinion? Appreciate any PRs! |
@dblock @rursprung I believe we should do that as part of #377, the later should allow raw request / response manipulation, strong -1 to open up any client transport internals. |
@reta Let's focus on the basic ask of exposing the HTTP status code. Can you explain what are your reasons not to allow the caller to explicitly be able to know whether the server responded with a 302 vs. a 301 for example, directly? |
@dblock in my opinion, the Java client general interface is typed and errors are reported using exceptions, the 302 or 301 is not relevant to the caller of typed API, the only relevant part is success or not, with generic client that would be possible to manipulate over raw request / response. |
Makes sense @reta, so what is a proposed change to be able to extract a 409 Conflict? Should it be a specialized exception? What should it inherit from? |
@reta: the problem is that |
@rursprung That could make sense, but maybe it's easier if |
Thanks @rursprung , or |
We should probably do both. I don't see a reason why |
Agree, at least it is worth looking, the reasons why |
i've created #756 to expose but i'm unsure how best to ensure that Line 503 in 9213138
everything else is a TransportException (usually wrapping a ResponseException ) or, IOException or similar (didn't check all of them). the story seems to be similar for the old RestClientTransport .so while every API seems to claim that it throws a OpenSearchException (something which it technically doesn't have to do as it's a RuntimeException ) i don't think that this is what's usually being thrown. changing that might even be considered a breaking change if someone explicitly catches a RuntimeException (or IOException or similar) at the moment to somehow handle that case.
as you're far more familiar with this library (i only just started to use it) you can probably judge better what the proper approach is. i'd suggest to maybe split this part out into a separate issue, where you clearly formulate the target picture and the expected impact. |
Thanks @rursprung , I think this is good change in any case, thank you.
Makes perfect sense, thank you. |
this allows accessing the HTTP status code of the response when an API returns a `ResponseException`. this was not possible through `getResponse` since `Response` itself is package-private and thus its members (even though they are marked as `public`) are not accessible to external consumers. solves #749 Signed-off-by: Ralph Ursprung <[email protected]>
With #756 merged, I renamed this issue to "Throw OpenSearchException on 409 Conflict" which I think represents the feature request we discussed above. Feel free to edit/close/reopen as you see fit! |
this allows accessing the HTTP status code of the response when an API returns a `ResponseException`. this was not possible through `getResponse` since `Response` itself is package-private and thus its members (even though they are marked as `public`) are not accessible to external consumers. solves #749 Signed-off-by: Ralph Ursprung <[email protected]> (cherry picked from commit 863518c)
@dblock: do you only want to change it from a |
I think when OpenSearch is generating a error response body it should be an Maybe everything should inherit from |
i think that sounds reasonable. kicking out |
Right, so proceed with caution. |
then i'd suggest to either rename the issue again (i'll abstain from doing it myself to make sure that this now reflects your plans) or raise a new one (or two: one for everything doable without a breaking change and one for the breaking change to be done later) and clearly outline what should be done and at which point. is there a release planning to know when a major release is planned / is ok to happen? |
We theoretically can make a major release anytime. I think I'd want to look at a PR and see if it's really worth it, and an UPGRADING.md that explains how it changes to users. I know it's potentially throw away work, but I think we all agree that changing exceptions being raised is kinda a big deal (TM). |
Is your feature request related to a problem?
note: i'm using the
ApacheHttpClient5Transport
APIs.i'm doing a request through
OpenSearchClient#create
because the API allows me to ensure that a document is only indexed once, as per the javadoc:opensearch-java/java-client/src/main/java/org/opensearch/client/opensearch/OpenSearchClient.java
Lines 329 to 338 in c0f51d0
however, if the document with this ID already exists then the API throws an exception instead of returning a response. and while the
ResponseException
would offer access to the actualResponse
:opensearch-java/java-client/src/main/java/org/opensearch/client/transport/httpclient5/ResponseException.java
Lines 92 to 94 in c0f51d0
which would also offer access to the HTTP status via
StatusLine
:opensearch-java/java-client/src/main/java/org/opensearch/client/transport/httpclient5/Response.java
Lines 84 to 86 in c0f51d0
the problem is that
Response
is package-private, so i cannot access any of its methods (even though they're marked aspublic
):opensearch-java/java-client/src/main/java/org/opensearch/client/transport/httpclient5/Response.java
Line 52 in c0f51d0
What solution would you like?
there should be a clear, canonical (and documented) way of accessing the HTTP status if such a request fails.
one possibility could be to make
Response
public (i don't understand why it isn't).What alternatives have you considered?
parsing the exception as a string to see if it contains "[HTTP/1.1 409 Conflict]" is at best an ugly hack as the string is not a guaranteed API
Do you have any additional context?
i wasn't sure whether to categorise this as a feature request (because it needs a new API to be exposed), a bug report (because i consider it wrong that i can't access this information) or a question (because i might just have missed a way of getting to that information; in that case it'd be good if it could be documented as i didn't find it in this repo!).
The text was updated successfully, but these errors were encountered: