[SERVER-71122] Get rid of the `WaitForCleanCorrectEvenAfterClearFollowedBySetFilteringMetadata` unit test Created: 07/Nov/22 Updated: 29/Oct/23 Resolved: 23/Nov/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 6.2.0-rc2, 6.3.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Pierlauro Sciarelli | Assignee: | Pierlauro Sciarelli |
| 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 | ||||||||
| Backport Requested: |
v6.2
|
||||||||
| Sprint: | Sharding EMEA 2022-11-28 | ||||||||
| Participants: | |||||||||
| Linked BF Score: | 5 | ||||||||
| Description |
|
The legacy range deleter was closely tighten to the metadata manager so this unit test was aimed to check that waitForClean was behaving well in case the metadata were cleared after scheduling a range deletion. With the new range deleter service that is independent from the metadata manager, the waitForClean behavior can't possibly be influenced by clearing or setting new metadata. Hence this unit test can go away. It also makes sense to get rid of it because the test gets stuck if the range deletion starts right between clearing and setting again the filtering metadata. The deadlock is not a bug, but a unit test lack since the onShardVersionMismatch invocation/response are not mocked. And mocking it would not add any value since the unit test is not that meaningful anymore. |
| Comments |
| Comment by Githook User [ 23/Nov/22 ] |
|
Author: {'name': 'Pierlauro Sciarelli', 'email': 'pierlauro.sciarelli@mongodb.com', 'username': 'pierlauro'}Message: |
| Comment by Githook User [ 23/Nov/22 ] |
|
Author: {'name': 'Pierlauro Sciarelli', 'email': 'pierlauro.sciarelli@mongodb.com', 'username': 'pierlauro'}Message: |