-
Notifications
You must be signed in to change notification settings - Fork 736
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
Type::getDocument() throws NotFoundException when a ResponseException is captured #687
Comments
Good point. Can you open a pull request with this change? |
I've just improved the raised exception in my PR. |
Ok, I now merged your pull request to have a first "improved" fix. I also went through your comments. What you say is: Exceptions from the $request object should no be catched. If later it is not a 200 response code, the exception is thrown anyway, right? |
Side note: If it makes sense, breaking BC is not a problem ;-) |
@ruflin Thanks!. That's it, the request exception should not be catched at all. A NotFoundException will be thrown if it's not a 200 OK response, and a ResponseException will be thrown if something went bad (ES response contains an error). |
Can we try that out in a new pull request and see what the "consequences" on the current tests are? |
The only broken test is TypeTest::testGetDocumentNotExistingIndex().
It seems that ES sends an error response in combination with a 404 header when the index is missing, that triggers the ResponseException which now goes uncatched. An easy fix would be to bring back the catch in Type::getDocument() but only throwing the NotFoundException in case of a 404 response code.
It feels odd being forced to handle 404s 2 times. Maybe the ResponseException should not be thrown by the transport if the response has a 404 http code (It's not really an exception)... but I suppose that will be a pretty big BC break. What do you think? |
Sorry, for the late reply. About the 404: From a theoretical point of view you are probably right about the 404 not throwing an exception. But the main question I ask is what the engineer expects. If he uses Elastica, he doesn't care too much if it is http or thrift in the background. So is 404 for him something he would expect an exception because something went "unexpected"? Or what are the main reasons for 404? Here it is, because the document was not found. Why was the documented not found? Because it didn't exist or was not populated yet. I would assume, an engineer doesn't use this call when he does not expect the document to exist? What do you think? |
NP, we're all pretty busy :p I think we should behave just like ES do: only throw a NotFound exception (ES response without any errors where found===false) if the document is not found because it hasn't been populated yet. If the reason for the document not being retrieved is another one like a bad request (i.e. child doc without parent parameter) or a missing index, the ResponseError triggered should not be captured, that way the engineer can easily know what failed. In case we need/want to be completely agnostic about the transport we should stop using $response->getTransferInfo() at all, because it's totally dependent on the HTTP transport (in fact, Having said that, my "final" proposal would be:
In order to pass the tests the only change required to testGetDocumentNotExistingIndex would be to expect a \Elastica\Exception\ResponseException |
I agree with both points. We should only trigger it if it is not found and outside the transport we should get rid of "404" checks etc. But we should treat these changes as two different pull requests, as the second one we should get in step by step. Can you open a pull request with your code above? |
Done! #713 |
Ok, since the main problem has been resolved by the #713 merge, should I close this issue?. Remember there are still a few $response->getTransferInfo() references within the code. |
@rmruano Can you open an new "Issue" so we don't forget to change these at a later stage? |
Sure, will do a little research first, if there are no inherited problems I'll just create a PR with it. Closing this issue. |
👍 |
Requesting existing documents without providing a routing parameter (for types with parent docs) rise a NotFoundException which is confusing and makes debugging a lot harder.
Original code at
Type::getDocument()
:I suggest to just leave the ResponseException uncatched (preferred) or to at least improve the exception message:
The text was updated successfully, but these errors were encountered: