[SERVER-74446] Investigate why delete_range_deletion_tasks_on_stepup_after_drop_collection.js times out waiting for fail point with catalog shard Created: 28/Feb/23 Updated: 10/Apr/23 Resolved: 10/Apr/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Jack Mulrow | Assignee: | Jack Mulrow |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Sharding NYC
|
||||||||
| Sprint: | Sharding NYC 2023-04-17 | ||||||||
| Participants: | |||||||||
| Description |
|
When delete_range_deletion_tasks_on_stepup_after_drop_collection.js is run with a catalog shard, the fail points it sets to pause metadata refreshes prevents the migration it runs from completing after stepup. This doesn't necessarily seem wrong, but doesn't happen with a dedicated config server, so we should further investigate and decide if this is ok. |
| Comments |
| Comment by Jack Mulrow [ 10/Apr/23 ] |
|
This was because the PeriodicShardedIndexConsistencyChecker ran on config server stepup and triggered a metadata refresh. Disabling the checker allows the test to pass without any modifications. This is will be done in |