[CI] org.elasticsearch.percolator.CandidateQueryTests.testDuel2 failure #49684
Assignees
Labels
:Search Relevance/Percolator
Reverse search: find queries that match a document
Team:Search Relevance
Meta label for the Search Relevance team in Elasticsearch
>test-failure
Triaged test failures from CI
Comments
iverase
added
>test-failure
|
Pinging @elastic/es-search (:Search/Percolator) |
iverase
changed the title
|
Wasn't able to reproduce locally either, but for anybody else giving it a try, here's the REPRODUCE line: Some details from the log that show the actual and the control documents: It appears in this case |
|
The query |
romseygeek
added a commit
that referenced
this issue
Dec 10, 2019
…49803) When the query analyzer examines a conjunction containing both terms and ranges, it should only include ranges in the minimum_should_match calculation if there are no other range queries on that same field within the conjunction. This is because we cannot build a selection query over disjoint ranges on the same field, and it is not easy to check if two range queries have an overlap. The current logic to calculate this just sets minimum_should_match to 1 or 0, dependent on whether or not the current range is over a field that has already been seen. However, this can be incorrect in the case that there are terms in the same match group which adjust the minimum_should_match downwards. Instead, the logic should be changed to match the terms extraction, whereby we adjust minimum_should_match downwards if we have already seen a range field. Fixes #49684
romseygeek
added a commit
that referenced
this issue
Dec 10, 2019
…49803) When the query analyzer examines a conjunction containing both terms and ranges, it should only include ranges in the minimum_should_match calculation if there are no other range queries on that same field within the conjunction. This is because we cannot build a selection query over disjoint ranges on the same field, and it is not easy to check if two range queries have an overlap. The current logic to calculate this just sets minimum_should_match to 1 or 0, dependent on whether or not the current range is over a field that has already been seen. However, this can be incorrect in the case that there are terms in the same match group which adjust the minimum_should_match downwards. Instead, the logic should be changed to match the terms extraction, whereby we adjust minimum_should_match downwards if we have already seen a range field. Fixes #49684
SivagurunathanV
pushed a commit
to SivagurunathanV/elasticsearch
that referenced
this issue
Jan 23, 2020
…lastic#49803) When the query analyzer examines a conjunction containing both terms and ranges, it should only include ranges in the minimum_should_match calculation if there are no other range queries on that same field within the conjunction. This is because we cannot build a selection query over disjoint ranges on the same field, and it is not easy to check if two range queries have an overlap. The current logic to calculate this just sets minimum_should_match to 1 or 0, dependent on whether or not the current range is over a field that has already been seen. However, this can be incorrect in the case that there are terms in the same match group which adjust the minimum_should_match downwards. Instead, the logic should be changed to match the terms extraction, whereby we adjust minimum_should_match downwards if we have already seen a range field. Fixes elastic#49684
This was referenced Feb 3, 2020
javanna
added
the
Team:Search Relevance
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This test seems to have been failing recently:
master: https://gradle-enterprise.elastic.co/s/eel3j36akwpam
7.x: https://gradle-enterprise.elastic.co/s/xjdre63zy2hmk
It does not reproduce locally. Failure:
The text was updated successfully, but these errors were encountered: