HDDS-16757. RenameKeys overwrites an existing destination key and still reports the pair as not renamed

[smengcl]

Generated-by: Claude Code (Opus 5.5)

What changes were proposed in this pull request?

In OMKeysRenameRequest#validateAndUpdateCache, the "Check if toKey exists" block marks the pair as not renamed but does not continue, unlike the other checks in the same loop. A batch rename onto an existing key therefore still renames the source key over the destination key:

• The destination row is replaced in the key table and its blocks are never added to the deleted table, so they are leaked.
• The response is PARTIAL_RENAME and lists the same pair in unRenamedKeys, so the client is told that the rename did not happen.
• If the source key does not exist either, the pair is listed twice in unRenamedKeys.

This PR adds the missing continue, so the pair is skipped and both keys are left unchanged. This matches the single key rename (OMKeyRenameRequest), which rejects the same case with KEY_ALREADY_EXISTS.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-16757

How was this patch tested?

Added TestOMKeysRenameRequest#testKeysRenameRequestToExistingKey. It batch renames one existing key onto another, together with a pair whose source key is missing, and asserts that the status is PARTIAL_RENAME, that each pair is listed exactly once in unRenamedKeys, and that both key table rows are unchanged. The test fails without the fix.

🤖 Generated with Claude Code

[Copilot]

🟢 Approval recommended

The narrow fix and regression assertions address the reported defect with no identified blocking issues; tests were not executed.

0 open findings

What changed in this PR

Fixes OM batch rename handling so an existing destination key is preserved and each rejected pair is reported only once.

Changes:

• Skip rename processing when the destination already exists.
• Add regression coverage for unchanged keys and accurate failure reporting.

File	Description
hadoop-ozone/​ozone-manager/​src/​test/​java/​org/​apache/​hadoop/​ozone/​om/​request/​key/​TestOMKeysRenameRequest.java	Tests destination preservation and single reporting of rejected pairs.
hadoop-ozone/​ozone-manager/​src/​main/​java/​org/​apache/​hadoop/​ozone/​om/​request/​key/​OMKeysRenameRequest.java	Adds the missing continue for existing destinations.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[jojochuang]

+1. The missing continue on “destination already exists” is clearly wrong: the loop records the pair in unRenamedKeys but still applies cache updates, so behavior disagrees with the response.

Example (overwrite): Bucket has reports/jan.pdf and reports/draft.pdf. Batch rename draft.pdf → jan.pdf should skip because jan.pdf exists. Without the fix, the client still gets partial failure / unrenamed, but OM overwrites jan.pdf anyway (metadata/block leak risk). With the fix, both keys stay unchanged.

Example (duplicate reporting): Same batch also includes missing.pdf → jan.pdf. Without continue, the existing-dest pair can be listed twice in unRenamedKeys (dest exists, then missing source). The new test catches both unchanged rows and exactly-once reporting.

Matches single-key rename semantics (KEY_ALREADY_EXISTS) in spirit via skip + PARTIAL_RENAME. Fine to merge once CI is green on current master.

[jojochuang]

Merged. Thanks @smengcl

[smengcl]

Thanks @jojochuang for the review.