Missing scroll ID no longer returns exception #5729
Assignees
Labels
Comments
|
@clintongormley wondering why we don't respond with a 400 or even a 404 when the scroll id does not exist (contains out of date information) ? |
|
We used to respond with a 500, but maybe a 404 would be more RESTful |
|
+1 on the 404 or 400. |
|
500 represents an internal server error, so anything in the 400 range (404 in particular representing the resource was not found) would be a lot better, thus indicating to the end user that the problem was on their end (input), rather than putting the blame onto Elasticsearch. So +1 to HTTP |
spinscale
added a commit
to spinscale/elasticsearch
that referenced
this issue
May 5, 2014
A bad/non-existing scroll ID used to return a 200, however a 404 might be more useful. Also, this PR returns the right Exception (SearchContextMissingException) in the Java API. Additionally: Added StatusToXContent interface and RestStatusToXContentListener listener, so the appropriate RestStatus can be returned Closes elastic#5729
spinscale
added a commit
that referenced
this issue
May 5, 2014
A bad/non-existing scroll ID used to return a 200, however a 404 might be more useful. Also, this PR returns the right Exception (SearchContextMissingException) in the Java API. Additionally: Added StatusToXContent interface and RestStatusToXContentListener listener, so the appropriate RestStatus can be returned Closes #5729
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As of commit 705c7e2 running a scroll request on a bad scroll ID no longer returns a 500 request error. Instead, each shard returns a failure but the overall request is a 200 OK.
/cc @kimchy
The text was updated successfully, but these errors were encountered: