[SERVER-70931] allow_partial_results_with_maxTimeMS_failpoints.js can set very short timeouts Created: 28/Oct/22 Updated: 29/Oct/23 Resolved: 28/Oct/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 6.2.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Steve Tarzia | Assignee: | Steve Tarzia |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Operating System: | ALL | ||||
| Sprint: | QE 2022-10-31 | ||||
| Participants: | |||||
| Linked BF Score: | 35 | ||||
| Description |
|
In BF-26761 and BF-26762, allow_partial_results_with_maxTimeMS_failpoints.js runs some find queries with a maxTimeMS timeout of only 30ms or 40ms, which does not leave enough margin for delays due to resource contention. This is controlled via the ampleTimeMS variable, which was being set to 10x the runtime of some query. When I wrote the test and tested locally, I was seeing ampleTimeMS values around 5 seconds. Evergreen environments are just a lot faster in some cases (probably due to using optimized instead of debug builds). To make this test more robust, and hopefully address those BFs, we should lower-bound ampleTimeMS with some more conservative value, like one second. |
| Comments |
| Comment by Githook User [ 28/Oct/22 ] |
|
Author: {'name': 'Steve Tarzia', 'email': 'steve.tarzia@mongodb.com', 'username': 'starzia'}Message: |