Bug: Renaming an EDP node duplicates UUID/externalId mapping entries

[jkevan]

Summary

When renaming an external node (on a DataSource that supports rename), the jahia_external_mapping table ends up with duplicate entries — two different UUIDs mapped to the same externalId.

Steps to reproduce

1. Mount a VFS provider into a website's files
2. Ensure you have a folder structure with subfolders and files
3. Visit the files/folders in jContent
4. Open a DB client (e.g., tools/dbQuery.jsp)
5. Run: SELECT * FROM jahia_external_mapping;
6. Note a folder's externalId and mapped UUID. Example for /compiledRules:

   | ffffff20-fc0f-408b-9d51-1aa121cc763c | /compiledRules | -2127518953 | 4c408ce2-d56e-47a4-8fc0-90bb93279b8a |
   

7. Rename the folder in jContent (e.g., compiledRules → test)
8. Re-run the query: SELECT * FROM jahia_external_mapping;

Expected result

One entry with the updated externalId:

| ffffff20-fc0f-408b-9d51-1aa121cc763c | /test | ... | 4c408ce2-d56e-47a4-8fc0-90bb93279b8a |

Actual result

Two entries with the same externalId but different UUIDs:

| ffffff20-fc0f-408b-9d51-1aa121cc763c | /test | -1933659697 | 4c408ce2-d56e-47a4-8fc0-90bb93279b8a |
| ffffff20-7c56-45b0-b0b6-346d0dce1ffe | /test | -1933659697 | 4c408ce2-d56e-47a4-8fc0-90bb93279b8a |

• ffffff20-fc0f-408b-9d51-1aa121cc763c — Original UUID (renamed)
• ffffff20-7c56-45b0-b0b6-346d0dce1ffe — Spurious new UUID ❌

Probable root cause

Race condition or incorrect operation ordering during rename:

1. Read operation on new path → triggers new UUID mapping
2. Then old entry is renamed

This results in two entries with the same externalId.

Impact

• Data inconsistency in the mapping table
• Potential issues with node resolution (which UUID is authoritative?)
• Table bloat over time with repeated renames

Acceptance criteria

• Renaming an EDP node updates the existing mapping entry (no new UUID created)
• No duplicate externalId entries in jahia_external_mapping after rename