Prevent repo rename/move via the path-less /move and /copy endpoints

[benpeter]

What

POST /move/{org}/{repo} and POST /copy/{org}/{repo} with no path under the repo act on the whole repo. That is a repo rename or move. It sweeps every key in the repo, including version and audit history under .da-versions.

This form is not in the API docs. The docs say move and copy take a path. The da.live UI reaches it too: at the org level you can hit rename on a repo, and it runs.

Why prevent it

The blast radius is large and easy to trigger by accident from the UI.

Version history does not move cleanly. The moved history keeps pointing at the old repo. With #303 blocking .da-versions destinations, a repo-root move now drops version history instead of carrying it.

Proposed fix

Reject a repo-root move or copy, a request whose source is the repo root with no sub-path. Return a 4xx. This is the authoritative gate. It covers every client: the da.live browse UI, Experience Workspace, and direct API calls.

Removing the matching repo rename action in the da.live UI is the companion issue: adobe/da-live#1121.

[auniverseaway]

Renaming a site [1] has always been supported and was purposeful (it's also just a folder / s3 prefix to DA).

This is a very common pre-production task. Someone makes a site, only to realize they want a different name before they start inviting people. They realize they didn't name it the same as they did for Edge Delivery, etc. etc. They talk to their colleague / customer and realize the name they chose was wrong. List goes on. 🙂

With HLX6, renaming a site will be a heavier task because these tasks will no longer be de-coupled. If you decide to ship this, you're only signing up for supporting people until HLX6 is live. At that point, you can use it as your backstop why DA is less nimble than it was previously.

My vote would be to use the "1000" file gate to determine if a site move is allowed. If there's more than 1000 files, send a 400.

[1] We try to avoid calling them repos - despite legacy codebase naming conventions in both Edge Delivery & DA.

[benpeter]

so if we want to keep site rename for legacy DA (agreed), the backend should guard it instead of rejecting every path-less move.

I suggest this contract:

• Reject POST /copy/{org}/{site} with 400 and site_copy_not_supported.
• Accept POST /move/{org}/{site} only as a same-org site rename.
• Reject nested or cross-org destinations.
• Return 409 and site_destination_exists if the destination root, .props, or descendant prefix exists.
• Count stored descendants below {org}/{site}/ with ListObjectsV2 and MaxKeys: 1000.
• Return 400 and site_rename_too_large when IsTruncated is true.
• Use that first listing as the rename work set. Do not list again after the limit check.

The count should use stored objects, not the UI's visible-file count. It includes versions, audit files, assets, and sidecars. The optional root object and {site}.props are outside the descendant prefix, so they do not count.

An allowed rename needs a dedicated storage path. The generic .da-versions guard from #303 must stay unchanged. The dedicated path can move the fixed history subtree to the new site prefix.

The rename should:

• preserve document IDs, version bodies, audit files, and other object metadata
• update each content object's Path metadata
• use create-only destination writes
• copy every object before deleting source objects
• return 204 only after all copies and deletes succeed
• return partial_failure if a copy or delete fails
• verify that the old descendant prefix is empty before returning 204

This needs tests at three levels.

Route tests:

• site-root copy returns site_copy_not_supported without calling storage
• site-root move dispatches to the rename path
• invalid destinations are rejected
• destination conflicts return site_destination_exists
• over-limit errors reach the client unchanged
• path-scoped copy and move keep their current behavior

Storage tests:

• IsTruncated: false permits the rename
• IsTruncated: true stops before any copy or delete
• the first listing is reused as the work set
• optional root and .props objects move when present
• versions and audit.txt map only to the new site prefix
• IDs stay unchanged while Path changes
• destination writes cannot overwrite existing objects
• no source delete starts before every copy succeeds
• copy, delete, and remaining-source failures do not return 204

The integration test should create a disposable site, document, and labelled version. It should rename the site through the route, then read content and history under the new name. The old content and history must be gone. A direct copy or move into .da-versions must still return 400.

The 1000 threshold is a product limit, not a correctness boundary. It limits the cost and blast radius of this legacy operation.

The companion UI work remains in adobe/da-live#1121.

@auniverseaway, @kptdobe -- does this look plausible?