-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Do not skip not available shard exception in search response #64337
Conversation
Today search responses do not report failures for shard that were not available for the search. So if one shard is not assigned on a search over 5 shards, the search response will report: ``` "_shards": { "total": 5, "successful": 4, "skipped": 0, "failed": 0 } ``` If all shards are unassigned, we report a generic search phase exception with no cause. It's easy to spot that `successful` is less than `total` in the response but not reporting the failure is misleading for users. This change removes the special handling of not available shards exception in search responses and treat them as any other failure that could occur on a shard. These exceptions will count in the `failed` section and will be reported in details in the `shard_failures` section. If all shards are unavailable, the search API will now return 404 NOT_FOUND as an indication that the search failed because it couldn't find any of the resources. Closes elastic#47700
Pinging @elastic/es-search (:Search/Search) |
Pinging @elastic/es-distributed (:Distributed/Distributed) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @jimczi for addressing this. Besides the comments below, I wonder if we should also add relevant shard-failures to the allowPartialSearchResults=false
case in AbstractSearchAsyncAction.run?
I think we can also remove the discrepancy check in executeNextPhase?
server/src/main/java/org/elasticsearch/action/search/AbstractSearchAsyncAction.java
Show resolved
Hide resolved
server/src/internalClusterTest/java/org/elasticsearch/search/basic/SearchRedStateIndexIT.java
Show resolved
Hide resolved
One more minor nit is the comment here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One more comment.
server/src/main/java/org/elasticsearch/action/search/SearchResponse.java
Show resolved
Hide resolved
Today search responses do not report failures for shard that were not available for the search. So if one shard is not assigned on a search over 5 shards, the search response will report: ``` "_shards": { "total": 5, "successful": 4, "skipped": 0, "failed": 0 } ``` If all shards are unassigned, we report a generic search phase exception with no cause. It's easy to spot that `successful` is less than `total` in the response but not reporting the failure is misleading for users. This change removes the special handling of not available shards exception in search responses and treat them as any other failure that could occur on a shard. These exceptions will count in the `failed` section and will be reported in details in the `shard_failures` section. If all shards are unavailable, the search API will now return 404 NOT_FOUND as an indication that the search failed because it couldn't find any of the resources. Closes #47700
Today search responses do not report failures for shard that were not available
for the search.
So if one shard is not assigned on a search over 5 shards, the
search response will report:
If all shards are unassigned, we report a generic search phase exception with no cause.
It's easy to spot that
successful
is less thantotal
in the response but not reportingthe failure is misleading for users.
This change removes the special handling of not available shards exception in search responses
and treat them as any other failure that could occur on a shard.
These exceptions will count in the
failed
section and will be reported in details inthe
shard_failures
section.Closes #47700