[SERVER-66756] Dropping a sharded timeseries collection could lead to inconsistent sharding catalog state Created: 25/May/22  Updated: 06/Dec/22  Resolved: 16/Sep/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 5.3.0-rc4, 5.0.9, 6.0.0-rc7
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Tommaso Tocci Assignee: [DO NOT USE] Backlog - Sharding EMEA
Resolution: Duplicate Votes: 0
Labels: timeseries_DDL_bug
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File reproducible_SERVER-66756.patch    
Issue Links:
Depends
depends on SERVER-67393 Sharding DDL coordinators implicitely... Closed
Assigned Teams:
Sharding EMEA
Operating System: ALL
Steps To Reproduce:

Apply the following patch on top of r5.0.9-14-g51168428972
reproducible_SERVER-66756.patch

and run jstests/sharding/timeseries_drop.js in the sharding suites to reproduce the problem.

Sprint: Sharding EMEA 2022-06-27
Participants:

 Description   

The concurrent execution of a shardCollection and a dropCollection on a timeseries collection could lead to an inconsistent catalog state, where the bucket nss is still registered in the sharding catalog config.collections but the view namespace is not registered locally on the primary shard.



 Comments   
Comment by Tommaso Tocci [ 16/Sep/22 ]

Fixed by SERVER-67393

Generated at Thu Feb 08 06:06:20 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.