Fixing for NPE when there is no query specified for the standard retriever#142479
Conversation
|
Pinging @elastic/es-search-relevance (Team:Search Relevance) |
|
Hi @pmpailis, I've created a changelog YAML for you. |
iverase
left a comment
There was a problem hiding this comment.
oh, it was just that, nice. LGTM
ioanatia
left a comment
There was a problem hiding this comment.
changes make sense to me.
consider that this is already valid and executes a match all:
GET wikipedia/_search
{
"retriever": {
"standard": {
}
}
}
I don't see why it shouldn't be supported when using empty standard retrievers in compound retrievers.
| - match: { hits.hits.1.fields.keyword.0: "keyword" } | ||
|
|
||
| --- | ||
| "rrf retriever with a standard retriever with no query but a sort": |
There was a problem hiding this comment.
do we need a NodeFeature here for bwc tests? I think only for these tests, since for the one in 10_standard_retriever.yml that should already work on main and previous versions (we just did not have a test for it yet).
💔 Backport failed
You can use sqren/backport to manually backport by running |
…iever (elastic#142479) (cherry picked from commit c1f55f2) # Conflicts: # x-pack/plugin/rank-rrf/src/main/java/org/elasticsearch/xpack/rank/RankRRFFeatures.java
💚 All backports created successfully
Questions ?Please refer to the Backport tool documentation |
queryparameter for astandardretriever is optional as per the documentation.However, it is possible to run to an NPE when using an "empty" standard retriever within a compound retriever like
rrforlinear, as there is no guard againstnullvalues when computingtopDocsQuery(in contrast to what we do in other methods).In this PR, we assume that an empty/null body equals to a
MatchAllDocsQuery(as in standard search API) and capture that only fortopDocsQuery. There were a couple of other options visited, like handling this on rewrite, or returning null, but the scope of the fix was changing significantly (e.g. we would also have to update all consumers oftopDocsQueryincludingRuleQueryBuilder) so this seemed like the most constrained, yet sufficient, solution. Happy to discuss more on this though.Closes #142336