[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".

Generated at Thu Feb 08 05:01:39 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.