[SERVER-40624] snapshot_cursor_commands_mongos.js shouldn't move same chunk twice during all shard reads set up Created: 12/Apr/19 Updated: 29/Oct/23 Resolved: 15/Apr/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.11 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Jack Mulrow | Assignee: | Jack Mulrow |
| 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 | ||||
| Sprint: | Sharding 2019-04-22 | ||||
| Participants: | |||||
| Linked BF Score: | 32 | ||||
| Description |
|
Before running the multiShardAllReads test case, snapshot_cursor_commands_mongos.js shards a collection, splits it at 4 and 8, moves the chunk containing 0 to shard0, 4 to shard1, and 7 to shard2, and asserts each shard owns one chunk by checking the config.chunks collection. The same chunk contains 4 and 7 though, so no chunk is guaranteed to end on shard1, but the test rarely fails because shard1 is almost always chosen as the primary shard, so the 3rd chunk that isn't moved will remain on it. Instead of relying on which shard is the primary without explicitly enforcing it, the test should be updated to move a different chunk to each shard instead of moving the same one twice. |
| Comments |
| Comment by Githook User [ 15/Apr/19 ] |
|
Author: {'email': 'jack.mulrow@mongodb.com', 'name': 'Jack Mulrow', 'username': 'jsmulrow'}Message: |