Repository navigation
fix(api): resolve indices_boost keys before searching, like ES - #2977
Open
amartya1523 wants to merge 2 commits into
Open
amartya1523 wants to merge 2 commits into
amartya1523 wants to merge 2 commits into
Conversation
ES resolves every indices_boost key against the cluster before the search runs (TransportSearchAction#resolveIndexBoosts), with the request's indices options. A key that names no index or alias is a 404 index_not_found_exception, or skipped under ignore_unavailable, and a cluster:index key is refused with illegal_argument_exception even then. XERJ applied boosts after the merge and dropped any key it could not match, so a typo in a boost answered 200 with every score unboosted. A date-math key now names the index it resolves to, as the search target already does; it was matched raw and never boosted. Retires the two search/40_indices_boost.yml catch-lenient entries.
Unknown and remote keys are refused; names, aliases, empty wildcards, date math, the object form and unknown names under ignore_unavailable still search 8000 with the boost applied.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
AI-assisted change, run and reviewed by @amartya1523.
What this changes, and why
ES resolves every
indices_boostkey against the cluster before the search runs (TransportSearchAction#resolveIndexBoosts). It uses the request's ownIndicesOptions, so a boost key follows the same rules as a search target:index_not_found_exception,no such index [x]ignore_unavailable=truecluster:index(remote)illegal_argument_exception, even withignore_unavailable<name-{now/d}>XERJ applied boosts after the cross-index merge and skipped any key it couldn't match. A typo in a boost answered 200 with every score unboosted, which looks like the boost "didn't matter". Two
catch-lenient.txtlines are this case:search/40_indices_boost.yml · Indices boost for nonexistent index/aliassearch/40_indices_boost.yml · Remote expressions not supported in indices boostFix (es_compat.rs):
index_boost_resolution_errorruns insearch_implafter target resolution, the closed-index pass andallow_no_indiceshandling, and before anything executes. It walks the keys in request order, as ES's loop does, so the first failing entry is the one reported:illegal_argument_exception:Cross-cluster calls are not supported in this context but remote indices were requested: [remote1:test_1]. Newis_remote_index_namemirrorsRemoteClusterAware#isRemoteIndexName: a:after the first character, unless the key is date math._alland wildcard keys pass, since they may match nothing.resolve_date_math_index, as the target path does). They pass if an open index or an alias has that name.ignore_unavailable=true, an unknown key is skipped.index_closed_exceptionand anything else getsXerjError::index_not_found. TheApiErrorrendering already gives ES'sno such index [x]envelope withresource.type,resource.idandindex_uuid.<test_2>booststest_2.Unchanged: alias and wildcard resolution, first-match-wins across overlapping keys (
putIfAbsentin ES,findhere), and the object shorthand{"idx": 2.0}.Evidence
New test module
indices_boost_resolution_tests(es_compat.rs), run against main first:First test:
[{nonexistent}, {test_1}]asserts the 404, the type andno such index [nonexistent].[{nonexistent}, {remote1:test_1}]withignore_unavailable=trueasserts the 400, the type and the exact reason.Second test: four requests:
ignore_unavailableEach asserts 2 hits,
test_2first, and its boosted_scoreof 2.0.Checks
cargo fmt -p xerj-api -- --checkcargo test --profile quick -p xerj-api --lib: 432 passed, 0 failed40_indices_boost.ymlcases now enforce it; their catch-lenient lines are deleted. The other five cases in that file (names, aliases, wildcards, multiple matches) use keys that resolve, so they're unaffected. No other YAML file or integration test usesindices_boost.Not run locally:
--releasebuilds,clippyand the integration binaries. Disk on this machine is at 99%; CI runs all of these.Provenance
quickprofile, based on main83c9f0d12.Arrays.toStringformatting.allow_no_indices=falsewith a wildcard key that matches nothing is still allowed here. ES would 404 that, but it's rare and I kept this change to concrete names._msearchand_search/templatedon't go throughsearch_impl's resolution, so they're not covered.