[SERVER-48680] Collection drop may fail in migration_fails_if_exists_in_rangedeletions.js test due to concurrent chunk migration Created: 09/Jun/20 Updated: 29/Oct/23 Resolved: 30/Jun/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 4.7.0 |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Max Hirschhorn | Assignee: | Matthew Saltz (Inactive) |
| 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 2020-06-29 | ||||
| Participants: | |||||
| Linked BF Score: | 25 | ||||
| Description |
|
The migration_fails_if_exists_in_rangedeletions.js test causes a chunk migration to block forever due to the presence of an overlapping range to clean up and the range deleter being paused using a failpoint on the recipient shard. Disabling the suspendRangeDeletion failpoint allows the chunk migration to proceed. If the ongoing chunk migration doesn't complete quickly enough, then the drop command to clean up the sharded collection before running the next test scenario will fail with a LockBusy error response. Re-running the moveChunk command which had its maxTimeMS expire after the suspendRangeDeletion failpoint was disabled would ensure the chunk migration is no longer in progress before the drop command is run. |
| Comments |
| Comment by Githook User [ 29/Jun/20 ] |
|
Author: {'name': 'Matthew Saltz', 'email': 'matthew.saltz@mongodb.com', 'username': 'saltzm'}Message: |