-
Type:
Task
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
Catalog and Routing
-
Fully Compatible
-
v9.0, v8.3, v8.0, v7.0
-
CAR Team 2026-08-17, CAR Team 2026-08-31, CAR Team 2026-09-14
-
0
-
🟥 DDL
-
None
-
None
-
None
-
None
-
None
-
None
Background
renameCollection with dropTarget: true must behave correctly when createCollection concurrently creates the target namespace.
Add an FSM workload that rotates a collection containing known test data between three namespaces:
- A: db1.coll1
- B: db1.coll2
- C: db1.coll3
Proposed Test
During setup, create namespace A with recognizable marker documents. Namespaces B and C should initially be absent.
Use a control collection containing a mutex and the current canonical namespace. Rename states acquire the mutex using an atomic findAndModify operation. The mutex serializes rename operations so their postconditions can be validated reliably. Create states do not acquire the mutex and therefore remain concurrent with rename.
The rename state will:
- Acquire the global rename mutex.
- Read the current canonical source namespace.
- Randomly select one of the other two namespaces as the target.
- Drop the selected target to open a window in which createCollection can race with renameCollection.
- Execute renameCollection with dropTarget: true.
- Verify that the expected marker documents exist in the target.
- Verify that the expected marker documents exist in the target and do not exist in the source. The source namespace may have been concurrently recreated after rename completed.
- Record the target as the new canonical namespace.
- Release the mutex in a finally block.
The create state will:
- Randomly select A, B, or C.
- Execute createCollection without acquiring the rename mutex.
- Accept either command success or NamespaceExists, depending on its ordering relative to rename.
Acceptance Criteria
- Rename operations rotate the canonical collection between A, B, and C.
- Concurrent rename operations are serialized using an atomic findAndModify mutex.
- createCollection remains concurrent with rename and is not protected by the mutex.
- Rename executes with dropTarget: true.
- The workload repeatedly opens a race window between dropping the target, creating it, and renaming onto it.
- After every successful rename, the target contains the expected marker documents and the source is absent.
- createCollection either succeeds or fails with NamespaceExists.
- The workload is tagged with does_not_support_stepdowns unless the mutex is made resilient to failover.
- The workload passes in the applicable concurrency suites.