[SERVER-64207] Too low of 'receiveChunkWaitForRangeDeleterTimeoutMS' value for migration_fails_if_exists_in_rangedeletions.js Created: 04/Mar/22 Updated: 29/Oct/23 Resolved: 01/Apr/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 6.0.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Kaloian Manassiev | Assignee: | Allison Easton |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | sharding-wfbf-day | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Operating System: | ALL | ||||
| Sprint: | Sharding EMEA 2022-04-04 | ||||
| Participants: | |||||
| Linked BF Score: | 33 | ||||
| Description |
|
The default receiveChunkWaitForRangeDeleterTimeoutMS value of 10 seconds is too low for migration_fails_if_exists_in_rangedeletions.js. Specifically, the test kicks-off migration which will block on range deletion here and then waits for 5 seconds before it turns off the failpoint. By then, 5 seconds have already passed, so only 5 more seconds are left for the range deletion to actually complete. We should increase it to at least 30 seconds for this whole test. Also, looking at other tests, which set the suspendRangeDeletion failpoint, it looks like:
May also be candidates in order to make them more robust. |
| Comments |
| Comment by Githook User [ 01/Apr/22 ] |
|
Author: {'name': 'Allison Easton', 'email': 'allison.easton@mongodb.com', 'username': 'allisoneaston'}Message: |