[SERVER-25875] Pull out "migrationCommitError" and "migrationCommitVersionError" failpoints and replace them with more comprehensive jstest coverage Created: 30/Aug/16 Updated: 10/Oct/16 Resolved: 10/Oct/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Dianna Hohensee (Inactive) | Assignee: | Dianna Hohensee (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Sprint: | Sharding 2016-09-19, Sharding 2016-10-10, Sharding 2016-10-31 |
| Participants: |
| Description |
|
The failpoints test that the source shard of a migration behaves correctly when they receive an error response from the config server due to the failpoints. However, they do not test the CommitChunkMigration command's ability to perceive such errors, since the checks are just being arbitrarily tripped by the failpoints. So instead, alter the config.chunks and config.locks collections directly in the JS test, in the middle of moveChunk commands, so that the CommitChunkMigration command will catch the errors on its own without failpoints doing so for the command. |
| Comments |
| Comment by Dianna Hohensee (Inactive) [ 10/Oct/16 ] |
|
While writing the JS test, it became apparent that unit testing would be by far more appropriate than JS integration testing trying to mimic unit testing with cumbersome failpoints. Created Writing the testing did accidentally shake out a segfault on the shard migration logic, however, so another lesson is that the MigrationSourceManager really needs unit testing as well. |