[SERVER-54999] Create state-agnostic resharding state machine failpoints Created: 05/Mar/21 Updated: 06/Dec/22 Resolved: 26/Oct/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Blake Oler | Assignee: | [DO NOT USE] Backlog - Sharding NYC |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | PM-234 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Sharding NYC
|
| Sprint: | Sharding 2021-03-08 |
| Participants: |
| Description |
|
These failpoints will hang before persisting the next resharding state transition. They will take in a state parameter to the failpoint data, and will hang before transition to that state. This will enable easier testing of aborting resharding from javascript. |
| Comments |
| Comment by Max Hirschhorn [ 26/Oct/21 ] |
|
I agree this proposal as written could have simplified parts of the resharding_abort_command.js test. I would want instead to invest time into ways resharding's primary-only services could have been more tested from C++ without needing so much orchestration. |
| Comment by Blake Oler [ 09/Mar/21 ] |
|
Moving to desired – we've decided that this is something we want to do eventually, just not now. |