[SERVER-54987] Wait for donor shards to have started resharding before asserting that commands are rejected in resharding_prohibited_commands.js Created: 05/Mar/21 Updated: 29/Oct/23 Resolved: 29/Mar/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 5.0.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Blake Oler | Assignee: | Kshitij Gupta |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | PM-234-M3, PM-234-T-lifecycle, sharding-wfbf-day | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Sprint: | Sharding 2021-03-22, Sharding 2021-04-05 | ||||
| Participants: | |||||
| Linked BF Score: | 51 | ||||
| Story Points: | 1 | ||||
| Description |
|
In this test, we verify that commands that synchronize with the donor shard in order to know to be rejected (collMod, createIndexes, dropIndexes) are indeed rejected. There exists a window after which the coordinator starts resharding and before the donor shard has reshardingFields in its cached metadata (to reject the command). This window itself is fine, because the MODE_S donor resharding lock synchronizes with the MODE_X locks taken for the conflicting commands. So this issue is test behavior only. To fix this, the test needs to wait for the donor shard to have written its local metadata document before verifying that commands are blocked. |
| Comments |
| Comment by Githook User [ 29/Mar/21 ] |
|
Author: {'name': 'Kshitij Gupta', 'email': 'kshitij.gupta@mongodb.com', 'username': 'kshitijng'}Message: |