[SERVER-43144] _configsvrDropCollection should handle user dropping config.system.sessions if config.system.sessions is not in sharding catalog Created: 03/Sep/19  Updated: 27/Oct/23  Resolved: 16/Sep/19

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Esha Maharishi (Inactive) 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

Issue Links:
Related
related to SERVER-42842 Unable to drop collection in admin da... Closed
Assigned Teams:
Sharding
Operating System: ALL
Participants:

 Description   

If the config.system.sessions collection is not in the sharding catalog, it's unclear whether the drop should be applied to all shards or just the config shard, because either of these could have occurred previously:

  • a previous drop attempt failed partway, and setShardVersion did not get sent to all shards
  • a previous drop attempt succeeded, and the user created their own config.system.sessions collection, which would have been created on the config shard

I encountered this while working on SERVER-42842. Dropping config.system.sessions is not really supported, and the behavior before SERVER-33973 was to run the drop only against the config shard, so that is the behavior I am preserving under SERVER-42842.



 Comments   
Comment by Esha Maharishi (Inactive) [ 16/Sep/19 ]

SERVER-42842 made dropping config.system.sessions always broadcast to shards, even if there is no entry for config.system.sessions in the sharding catalog.

Comment by Mira Carey [ 16/Sep/19 ]

We've made dropping config.system.sessions work in sharded and unsharded cases elsewhere, removing the need for this ticket

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