-
Notifications
You must be signed in to change notification settings - Fork 350
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
Allowing failed splits in root search. #5440
Conversation
f518830
to
0dfec8f
Compare
47abca3
to
a2401d8
Compare
This PR adds a query string parameter (`allow_partial_search_results`) in the elasticsearch api controlling encounterring an error on a subset of the splits, should fail a search query or if a response (reflecting the partial set of successful splits) should be returned. It changes the behavior of the root search gRPC call, that will not return an error in presence of partial split errors, but instead returns the list of splits that failed. This PR also changes the default behavior of the elasticsearch rest API: following elasticsearch behavior on failing shards, quickwit will allow split errors. The Quickwit API default behavior, on the other hand, is unchanged. Closes #5411
a2401d8
to
8754e83
Compare
e178af0
to
6a6ee22
Compare
Co-authored-by: trinity-1686a <[email protected]>
6a6ee22
to
ea024cd
Compare
// Ideally, we would have wanted to reuse the setting from the initial search request. | ||
// However, passing that parameter is cumbersome and not necessary: | ||
// if we have a valid `scroll_id` it means that the search request was successful. | ||
// We can therefore allow failed splits, it won't make any difference. |
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.
i agree it's cumbersome, and i'm fine with it being left as TODO.
I'm not convinced by the argument that if we have a scroll id, search was successful. After a few pages, we need to do more search, which might hit a missing split (or fail for whatever reason), so an initial success only guarantees we're okay for so much calls.
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.
:( yes you are correct.
0e87fe3
to
d922852
Compare
The logic is now aligned with what is done for queries: we check the schema at the root level. If the aggregation does not make sense for the current index docmapping, the query is rejected.
d922852
to
8a166b7
Compare
(I also tested the option by removing splits on a running quickwit instance)