[SERVER-56023] listCollections can return empty metadata for a collection which has been concurrently dropped Created: 12/Apr/21 Updated: 29/Oct/23 Resolved: 20/May/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 5.0.0-rc0, 5.1.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Nicholas Zolnierz | Assignee: | Henrik Edin |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||||||||||||||||||
| Backport Requested: |
v5.0
|
||||||||||||||||||||||||||||||||||||||||||||||||
| Sprint: | Execution Team 2021-05-17, Execution Team 2021-05-31 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||||||
| Linked BF Score: | 158 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
This is very similar to One possible downstream impact for this is a failed shardCollection command when try to extract the UUID of the collection to shard. |
| Comments |
| Comment by Vivian Ge (Inactive) [ 06/Oct/21 ] |
|
Updating the fixversion since branching activities occurred yesterday. This ticket will be in rc0 when it’s been triggered. For more active release information, please keep an eye on #server-release. Thank you! |
| Comment by Githook User [ 24/May/21 ] |
|
Author: {'name': 'Henrik Edin', 'email': 'henrik.edin@mongodb.com', 'username': 'henrikedin'}Message: All updates to the metadata needs to happen through the Collection, moved interfaces from the DurableCatalog to the Collection. Multikey handle is special as it needs to happen without exclusive access to the Collection. Implemented isolation for the Collection metadata when multikey is changed. It handles multi-doc transactions and is only commited to the Collection instance after the write to the durable catalog successfully commits. listCollections and listIndexes can now safetly read the metadata cache without needing to read from the durable catalog making them safe to do without Collection level locks. (cherry picked from commit 11de948b0c50df7d12de09ae0f01e791fc5d70d7) |
| Comment by Githook User [ 24/May/21 ] |
|
Author: {'name': 'Henrik Edin', 'email': 'henrik.edin@mongodb.com', 'username': 'henrikedin'}Message: (cherry picked from commit 15e97c021b4e1feba110f31a563076980794d0a5) |
| Comment by Githook User [ 20/May/21 ] |
|
Author: {'name': 'Henrik Edin', 'email': 'henrik.edin@mongodb.com', 'username': 'henrikedin'}Message: All updates to the metadata needs to happen through the Collection, moved interfaces from the DurableCatalog to the Collection. Multikey handle is special as it needs to happen without exclusive access to the Collection. Implemented isolation for the Collection metadata when multikey is changed. It handles multi-doc transactions and is only commited to the Collection instance after the write to the durable catalog successfully commits. listCollections and listIndexes can now safetly read the metadata cache without needing to read from the durable catalog making them safe to do without Collection level locks. |
| Comment by Githook User [ 20/May/21 ] |
|
Author: {'name': 'Henrik Edin', 'email': 'henrik.edin@mongodb.com', 'username': 'henrikedin'}Message: |
| Comment by Nicholas Zolnierz [ 12/Apr/21 ] |
|
Note that as of SERVER-54918, the shardCollection path changed to not use listCollections and instead use AutoGetCollection to obtain the UUID of the target collection. |