[SERVER-51696] Find a way to verify writes to various resharding-related collections as part of a POS-driven operation in resharding_coordinator_test.cpp Created: 16/Oct/20 Updated: 06/Dec/22 Resolved: 05/Jun/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: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Sharding NYC
|
||||||||||||||||
| Participants: | |||||||||||||||||
| Story Points: | 2 | ||||||||||||||||
| Comments |
| Comment by Max Hirschhorn [ 05/Jun/21 ] |
|
A new ReshardingCoordinatorServiceTest fixture was added under |
| Comment by Max Hirschhorn [ 31/Dec/20 ] |
Note that these failpoints were already introduced as part of I think it would be good to clarify what this ticket is meant to achieve.
I think the JavaScript testing has reached a sufficient point to say the resharding coordinator triggers all of the state transitions necessary to get all the way through the operation. It seems like it could be useful to have testing which asserts specifically on the mechanics of how those state transitions happen. For example:
One aspect of resharding_coordinator_test.cpp that I had felt could be improved is how the test cases simulate what ReshardingCoordinator would be doing and aren't actually running the primary-only service Instance. |
| Comment by Haley Connelly [ 03/Nov/20 ] |
|
Note: We spoke offline and determined this won't be ready until MS1 is complete. |
| Comment by Blake Oler [ 02/Nov/20 ] |
|
Notes for implementer: Max wants a failpoint to hang write before writing down that we've committed, to verify that both the temporary and original have the same data. |