-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Faster filtering for unavailable indices #78544
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
Changes from all commits
fd23d54
c483e4d
3b10fa2
af276f1
734a7ad
b4237b4
f9a2c88
4268c27
90c1b00
69f56c6
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -695,7 +695,7 @@ public void testResolveNoExpandStrict() { | |
| } | ||
|
|
||
| public void testResolveNoExpandIgnoreUnavailable() { | ||
| SearchRequest request = new SearchRequest("missing*"); | ||
| SearchRequest request = new SearchRequest(randomFrom("missing*", "*")); | ||
|
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. argh .. I realised there is another edge case where we cannot safely skip filtering unavailable indices for a single As a result, I decided to drop my original proposal for the special handling and just leave Tim's change for faster loop. |
||
| request.indicesOptions(IndicesOptions.fromOptions(true, true, false, false)); | ||
| assertNoIndices(request, resolveIndices(request, buildAuthorizedIndices(user, SearchAction.NAME))); | ||
| } | ||
|
|
||
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 think you realized that the lone
*index expression withreplaceWildcards == falsenow behaves slightly different.Before, Security would leave the
*in-place and would leave core do its thing (fail in some way).Now, we either fail in Security with index not found exception, or pass it to core as
*, -*, which would also probably fail (again because request options say to not replace wildcards).I'm not terribly concerned, though.
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.
No, I didn't realise that. Thanks for raising it. I was relying on the tests to catch any inconsistent behaviour and it seems we have some test gap.
I did some more digging and found there are behaviour differences:
GET */_search?expand_wildcards=none&allow_no_indices=false->404Error404Error404ErrorGET */_search?expand_wildcards=none&allow_no_indices=true->404ErrorThe difference is about how
allow_no_indicesis intepreted. I'd argue that the existing behaviour is not accurate becauseallow_no_indicesimplies "expansion" of either wildcards or aliases. But the request explicilty asks for no expansion. Hence the name*should be treated as a literal index name. In that case, the relevant option should beignore_unavailableinstead ofallow_no_indices. That is the following request should return empty resultGET */_search?expand_wildcards=none&ignore_unavailable=trueBased on the following comment, it seems that core is not fully convinced with its own behaviour either.
elasticsearch/server/src/main/java/org/elasticsearch/cluster/metadata/IndexNameExpressionResolver.java
Lines 218 to 223 in eeb09f0
That said, behaviour change is what I tried to avoid and it is the reason why I bothered to add special handling for error message. I'll make some adjustments. Thanks again for noticing it.