Background

renameCollection with dropTarget: false 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: false.
• If the rename succeeds, 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.
• If the rename fails with NamespaceExists, verify that the expected marker documents remain in the source.
• Record the target as the new canonical namespace only after a successful rename.
• 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 after successful renames.
• 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: false.
• The workload repeatedly opens a race window between dropping the target, creating it, and renaming onto it.
• A rename succeeds if the target remains absent or fails with NamespaceExists if the target is concurrently created.
• After a successful rename, the target contains the expected marker documents and the source does not contain those marker documents. The source namespace may have been concurrently recreated.
• If rename fails with NamespaceExists, the source retains the expected marker documents and remains the canonical namespace.
• createCollection either succeeds or fails with NamespaceExists.
• The workload includes tags for unsupported stepdown configurations.
• The workload passes in the applicable concurrency suites.