[SERVER-42873] Dropping config.shards can cause a concurrent removeShard operation to remain in 'draining' state indefinitely Created: 19/Aug/19 Updated: 27/Oct/23 Resolved: 30/Aug/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Bernard Gorman | Assignee: | [DO NOT USE] Backlog - Sharding Team |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Sharding
|
| Operating System: | ALL |
| Participants: |
| Comments |
| Comment by Bernard Gorman [ 26/Aug/19 ] |
|
kaloian.manassiev: yes, I don't think this is a real-world "bug" so much as a BF nuisance - I just made a note of it while writing the concurrency suite so that Sharding would be aware of it, in case it might motivate some future work to outright ban direct metadata writes. I'm happy for it to be closed as Won't Fix. |
| Comment by Kaloian Manassiev [ 26/Aug/19 ] |
|
bernard.gorman, is this bug just a BF nuisance? Generally, dropping any of these system collections is not a supported operation and only someone with administrative privileges can do it, so a removeShard operation remaining stuck is the least of the problems that can arise. I am thinking if closing this ticket as "Won't Fix". |