—-----------------------------------------------------

Original description

Problem

A cross-database renameCollection can lose the renamed collection if the primary node of the data-bearing participant shard's replica set steps down after the target has been created and the source dropped, but before the participant restores its range-deletion state and advances beyond kRenameLocalAndRestoreRangeDeletions.

After recovery:

• The source is absent because it was already dropped.
• The target exists with the fresh UUID assigned to the cross-database rename.
• The recovered participant re-executes kRenameLocalAndRestoreRangeDeletions.

The recovered phase invokes renameOrDropTarget(): participant phase invocation.

renameOrDropTarget() only recognizes a completed rename when the target UUID equals the original source UUID: participant idempotency check.

That check works for same-database renames, but cross-database renames deliberately assign a fresh target UUID: cross-database target UUID creation.

Although newTargetCollectionUuid is forwarded into the participant phase, it is not considered by the idempotency check. renameOrDropTarget() therefore invokes validateAndRunRenameCollection().

The underlying cross-database rename returns NamespaceNotFound because the source is absent, and uassertStatusOK() converts that status into an exception: missing-source path and validateAndRunRenameCollection.

Control returns to the NamespaceNotFound catch block in renameOrDropTarget(), which invokes dropCollectionLocally() on the successfully renamed target: target drop.

Observed sequence

1. An untracked collection is renamed across databases.
2. The participant creates the target with a fresh UUID.
3. The temporary collection is renamed to the target and the source is dropped.
4. A shard stepdown interrupts the participant while restoring range-deletion state.
5. The new primary recovers and repeats the local rename phase.
6. The source is absent and the target UUID differs from the source UUID.
7. The participant handles NamespaceNotFound by dropping the successfully renamed target.
8. The coordinator completes, leaving both source and target absent.

Expected behavior

A recovered participant must recognize that the rename has already completed when the target UUID matches newTargetCollectionUuid. The target collection and its documents must remain intact.

Actual behavior

The recovered participant drops the target collection. Since the source was already dropped, both namespaces are absent after the operation, presenting a data-loss risk.

Deterministic reproducer

A focused C++ reproducer has been pushed:

• Reproducer PR (does not contain fix) for verification

The test directly models the recovered state:

• Source namespace is absent.
• Target exists with a document and a fresh UUID.
• newTargetCollectionUuid matches the target UUID.
• The original source UUID is different.
• Re-running the participant unexpectedly drops the target.

Run with:

bazel run +rename_collection_participant_service_test 

The test currently fails with:

FAIL: Value of: targetUUIDAfterRetry
  Actual: false
Expected: true
The recovered participant dropped the already-renamed cross-database target

Acceptance criteria

• Participant retries recognize a completed cross-database rename using newTargetCollectionUuid.
• A missing source does not cause the successfully renamed target to be dropped.
• The target UUID and documents are preserved.
• The deterministic reproducer passes.
• Same-database rename and legitimate non-data-bearing participant behavior remain unchanged.