-
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 flaky test **/testSearchTaskCancellationWithHighCpu
& shard variant
#7978
Fix flaky test **/testSearchTaskCancellationWithHighCpu
& shard variant
#7978
Conversation
Signed-off-by: Stephen Crawford <[email protected]>
**/SearchBackpressureIT.testSearchTaskCancellationWithHighCpu
**/testSearchTaskCancellationWithHighCpu
Gradle Check (Jenkins) Run Completed with:
|
Codecov Report
@@ Coverage Diff @@
## main #7978 +/- ##
============================================
+ Coverage 70.84% 70.86% +0.01%
+ Complexity 56530 56502 -28
============================================
Files 4714 4714
Lines 267213 267213
Branches 39182 39182
============================================
+ Hits 189310 189348 +38
- Misses 61916 61920 +4
+ Partials 15987 15945 -42 |
Well, I guess that did not work as it appeared locally... I suspect the runner is more powerful then my local computer so performs the operations faster and still comes in under the threshold. Going to look into finding a more appropriate value or way to prevent the different systems from getting different results. |
Signed-off-by: Stephen Crawford <[email protected]>
Signed-off-by: Stephen Crawford <[email protected]>
Signed-off-by: Stephen Crawford <[email protected]>
**/testSearchTaskCancellationWithHighCpu
**/testSearchTaskCancellationWithHighCpu
& shard variant
Gradle Check (Jenkins) Run Completed with:
|
Gradle Check (Jenkins) Run Completed with:
|
Gradle Check (Jenkins) Run Completed with:
|
Gradle Check (Jenkins) Run Completed with:
|
Gradle Check (Jenkins) Run Completed with:
|
Should be set @reta. Dropped the threshold a lot, I don't know at what point it becomes unreasonable, but since the tests are just verifying that the CpuUsageTracker throws when the time is above the threshold, it should be fine. The purpose does not seem to be to check the performance so much as make sure there is an appropriate exception. There are two more flaky tests that are from other classes. I can look at those next. |
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 @scrawfor99 !
…iant (#7978) * Fix flake Signed-off-by: Stephen Crawford <[email protected]> * Drop threshold further Signed-off-by: Stephen Crawford <[email protected]> * Remove empty line Signed-off-by: Stephen Crawford <[email protected]> * Change threshold for ShardCPU test Signed-off-by: Stephen Crawford <[email protected]> --------- Signed-off-by: Stephen Crawford <[email protected]> (cherry picked from commit 812b3e3) Signed-off-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
…iant (#7978) (#7987) * Fix flake * Drop threshold further * Remove empty line * Change threshold for ShardCPU test --------- (cherry picked from commit 812b3e3) Signed-off-by: Stephen Crawford <[email protected]> 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>
…iant (opensearch-project#7978) (opensearch-project#7987) * Fix flake * Drop threshold further * Remove empty line * Change threshold for ShardCPU test --------- (cherry picked from commit 812b3e3) Signed-off-by: Stephen Crawford <[email protected]> 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>
…iant (opensearch-project#7978) * Fix flake Signed-off-by: Stephen Crawford <[email protected]> * Drop threshold further Signed-off-by: Stephen Crawford <[email protected]> * Remove empty line Signed-off-by: Stephen Crawford <[email protected]> * Change threshold for ShardCPU test Signed-off-by: Stephen Crawford <[email protected]> --------- Signed-off-by: Stephen Crawford <[email protected]> Signed-off-by: Rishab Nahata <[email protected]>
…iant (opensearch-project#7978) * Fix flake Signed-off-by: Stephen Crawford <[email protected]> * Drop threshold further Signed-off-by: Stephen Crawford <[email protected]> * Remove empty line Signed-off-by: Stephen Crawford <[email protected]> * Change threshold for ShardCPU test Signed-off-by: Stephen Crawford <[email protected]> --------- Signed-off-by: Stephen Crawford <[email protected]> Signed-off-by: Shivansh Arora <[email protected]>
Description
This change resolves the issue of the SearchBackpressureIT.testSearchTaskCancellationWithHighCPU encountered here #7972.
The issue was happening because the selected timelimit threshold for the test was too high leading the test to pass on occasion. To check this, I ran the test with additional logging at line 51 of the
CpuUsageTracker.java
class which is what processes the reason for failure. I then ran the test to verify the issue and found that the Optional.empty() was being returned in cases where the completion time of the request was around .9 seconds (just under the 1 second threshold).I dropped the threshold to be .05 seconds so that it should always trigger. Since this value is just for testing that the correct exception messages are logged, it should not matter what the value is. The default value remains 3 seconds and is unaffected by this change.
Related Issues
#7972
Check List
New functionality includes testing.ll tests passNew functionality has been documented.New functionality has javadoc addedCommit changes are listed out in CHANGELOG.md file (See: Changelog)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.