[SERVER-35319] renameCollection should re-register the source collection's UUID when interrupted Created: 31/May/18  Updated: 27/Oct/23  Resolved: 28/Jan/19

Status: Closed
Project: Core Server
Component/s: Catalog
Affects Version/s: 4.0.0-rc1, 4.1.1
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Louis Williams Assignee: Xiangyu Yao (Inactive)
Resolution: Gone away Votes: 0
Labels: nyc
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-35563 The UUIDCatalog onCreateCollection ob... Closed
is related to SERVER-38469 Allow interrupts in renameCollection Closed
is related to SERVER-30229 Clean up UUIDCatalog registration Closed
Operating System: ALL
Sprint: Storage NYC 2018-12-31, Storage NYC 2019-01-28
Participants:
Linked BF Score: 115

 Description   

It is possible to interrupt a renameCollection from "source" to "target" such that the UUID of "source" is no longer mapped to "source", but nothing at all.

This can cause an invariant when using collMod to access the collection by UUID.

The UUIDCatalog::onRenameCollection observer correctly implements this behavior, but because UUIDCatalog::onCreateCollection is called before the onRenameCollection observer is called, this leaves the UUID catalog in an incorrect state.



 Comments   
Comment by Xiangyu Yao (Inactive) [ 28/Jan/19 ]

After SERVER-37443, renameCollection no longer uses createCollection as one of the steps so this problem is gone.

Comment by Ian Whalen (Inactive) [ 12/Oct/18 ]

Whoever picks this up should confirm that it is indeed already fixed. If not, please put this back into Needs Scheduling with any additional info.

Comment by Ian Whalen (Inactive) [ 08/Jun/18 ]

maria.vankeulen to find and link the related ticket.

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