[SERVER-53460] Use assert.soon to check that resharding content local to each participant is cleaned up Created: 19/Dec/20 Updated: 29/Oct/23 Resolved: 05/Jan/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 4.9.0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Sarah Zhou | Assignee: | Sarah Zhou |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | PM-234-M2, PM-234-T-lifecycle | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Sprint: | Sharding 2020-12-28, Sharding 2021-01-11 | ||||||||||||
| Participants: | |||||||||||||
| Linked BF Score: | 35 | ||||||||||||
| Story Points: | 1 | ||||||||||||
| Description |
|
During the teardown of the resharding fixture, we find that the donor document still exists when we expect it to have been already deleted. Because the ReshardingCoordinatorService will complete after waiting for donors to transition to kDone and we don't remove the donor document until after the donor transitions to kDone, it is possible that the donor document removal may not be seen immediately after the reshardCollection completes. We can fix this issue if we change the failing assertion to an assert.soon. We also need to change the recipient document deletion assertion to an assert.soon as well. |
| Comments |
| Comment by Githook User [ 05/Jan/21 ] |
|
Author: {'name': 'Sarah Zhou', 'email': 'sarah.zhou@mongodb.com', 'username': 'cookiestuf'}Message: |
| Comment by Max Hirschhorn [ 30/Dec/20 ] |
|
Author: {'name': 'Max Hirschhorn', 'email': 'max.hirschhorn@mongodb.com', 'username': 'visemet'}Message: Switches over most of the tests either running reshardCollection
The config.localReshardingOperations. {donor,recipient} collections are |