-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Fix SearchQueryIT to not depend on percentage #11233
Fix SearchQueryIT to not depend on percentage #11233
Conversation
The CommonTermsQuery tests in SearchQueryIT had one case that depended on the default cutoff frequency percentage. A recent change for concurrent search increased the number of deleted documents that could be indexed in the "indexRandom" helper method, and it turns out the cutoff percentage is calculated from a max docs value that includes deleted docs. This change replaces the default percentage with an absolute value (number of documents that must match) so it is no longer susceptible to behavior change due to number of deleted documents. Signed-off-by: Andrew Ross <andrross@amazon.com>
Compatibility status:Checks if related components are compatible with change 1d6543b Incompatible componentsIncompatible components: [https://github.com/opensearch-project/k-nn.git, https://github.com/opensearch-project/performance-analyzer.git] Skipped componentsCompatible componentsCompatible components: [https://github.com/opensearch-project/security-analytics.git, https://github.com/opensearch-project/observability.git, https://github.com/opensearch-project/opensearch-oci-object-storage.git, https://github.com/opensearch-project/job-scheduler.git, https://github.com/opensearch-project/ml-commons.git, https://github.com/opensearch-project/custom-codecs.git, https://github.com/opensearch-project/sql.git, https://github.com/opensearch-project/notifications.git, https://github.com/opensearch-project/security.git, https://github.com/opensearch-project/cross-cluster-replication.git, https://github.com/opensearch-project/asynchronous-search.git, https://github.com/opensearch-project/neural-search.git, https://github.com/opensearch-project/reporting.git, https://github.com/opensearch-project/geospatial.git, https://github.com/opensearch-project/index-management.git, https://github.com/opensearch-project/common-utils.git, https://github.com/opensearch-project/anomaly-detection.git, https://github.com/opensearch-project/alerting.git, https://github.com/opensearch-project/performance-analyzer-rca.git] |
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.
Thanks a lot @andrross !
Thanks for looking into this! Is the behavior of the cutoff percentage accounting for deleted docs correct or should we also track fixing that underlying issue? It's not clear to me why that would make this test flaky instead of always failing. |
That logic is defined in Lucene: https://github.com/apache/lucene/blob/a26a80c89c2e625607b8d2ddb74230b57076d1da/lucene/queries/src/java/org/apache/lucene/queries/CommonTermsQuery.java#L113 ( I would argue that the logic is valid, using |
❌ Gradle check result for 1d6543b: FAILURE Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
@msfroh thanks for the details, that makes sense to me. On a different note, it looks like this common terms query is actually deprecated from Elastic 7.3 so wonder if we should also move towards completely removing it as well: OpenSearch/server/src/main/java/org/opensearch/index/query/CommonTermsQueryBuilder.java Lines 55 to 70 in aca2e9d
|
@jed326 I was able to get it to deterministically fail with a particular random seed. The reason was due to this line: https://github.com/opensearch-project/OpenSearch/blob/main/test/framework/src/main/java/org/opensearch/test/OpenSearchIntegTestCase.java#L1700 If the |
❌ Gradle check result for 1d6543b: Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
❕ Gradle check result for 1d6543b: UNSTABLE
Please review all flaky tests that succeeded after retry and create an issue if one does not already exist to track the flaky failure. |
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #11233 +/- ##
============================================
+ Coverage 71.09% 71.12% +0.03%
- Complexity 58752 58757 +5
============================================
Files 4888 4888
Lines 277207 277222 +15
Branches 40282 40287 +5
============================================
+ Hits 197077 197177 +100
+ Misses 63654 63563 -91
- Partials 16476 16482 +6 ☔ View full report in Codecov by Sentry. |
The CommonTermsQuery tests in SearchQueryIT had one case that depended on the default cutoff frequency percentage. A recent change for concurrent search increased the number of deleted documents that could be indexed in the "indexRandom" helper method, and it turns out the cutoff percentage is calculated from a max docs value that includes deleted docs. This change replaces the default percentage with an absolute value (number of documents that must match) so it is no longer susceptible to behavior change due to number of deleted documents. Signed-off-by: Andrew Ross <andrross@amazon.com> (cherry picked from commit 3509500) Signed-off-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
The CommonTermsQuery tests in SearchQueryIT had one case that depended on the default cutoff frequency percentage. A recent change for concurrent search increased the number of deleted documents that could be indexed in the "indexRandom" helper method, and it turns out the cutoff percentage is calculated from a max docs value that includes deleted docs. This change replaces the default percentage with an absolute value (number of documents that must match) so it is no longer susceptible to behavior change due to number of deleted documents. (cherry picked from commit 3509500) Signed-off-by: Andrew Ross <andrross@amazon.com> Signed-off-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
The CommonTermsQuery tests in SearchQueryIT had one case that depended on the default cutoff frequency percentage. A recent change for concurrent search increased the number of deleted documents that could be indexed in the "indexRandom" helper method, and it turns out the cutoff percentage is calculated from a max docs value that includes deleted docs. This change replaces the default percentage with an absolute value (number of documents that must match) so it is no longer susceptible to behavior change due to number of deleted documents. Signed-off-by: Andrew Ross <andrross@amazon.com>
The CommonTermsQuery tests in SearchQueryIT had one case that depended on the default cutoff frequency percentage. A recent change for concurrent search increased the number of deleted documents that could be indexed in the "indexRandom" helper method, and it turns out the cutoff percentage is calculated from a max docs value that includes deleted docs. This change replaces the default percentage with an absolute value (number of documents that must match) so it is no longer susceptible to behavior change due to number of deleted documents. Signed-off-by: Andrew Ross <andrross@amazon.com>
The CommonTermsQuery tests in SearchQueryIT had one case that depended on the default cutoff frequency percentage. A recent change for concurrent search increased the number of deleted documents that could be indexed in the "indexRandom" helper method, and it turns out the cutoff percentage is calculated from a max docs value that includes deleted docs. This change replaces the default percentage with an absolute value (number of documents that must match) so it is no longer susceptible to behavior change due to number of deleted documents. Signed-off-by: Andrew Ross <andrross@amazon.com> Signed-off-by: Shivansh Arora <hishiv@amazon.com>
The CommonTermsQuery tests in SearchQueryIT had one case that depended on the default cutoff frequency percentage. A recent change for concurrent search increased the number of deleted documents that could be indexed in the "indexRandom" helper method, and it turns out the cutoff percentage is calculated from a max docs value that includes deleted docs. This change replaces the default percentage with an absolute value (number of documents that must match) so it is no longer susceptible to behavior change due to number of deleted documents.
Related Issues
Resolves #11208
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.