Recover file deletion when storage needs attention

Removing a document now records the storage cleanup work before the document disappears from its wedding. This lets the system recover when a storage service is unavailable or a response is lost.

What removal changes immediately

For a private file, removal marks the stored asset for deletion and disables new application download links immediately. The cleanup worker then asks storage to remove the object. If that request fails, the asset remains blocked and the cleanup record remains available.

Older uploads can use public blob storage. The cleanup record preserves both the original URL and pathname after document removal. A legacy public URL may remain reachable until storage confirms deletion. The worker only attempts automatic legacy deletion for the recognized storage URL shape; an unexpected source stays available for manual review instead of being sent to an arbitrary destination.

Recover a failed deletion

Suppose you remove a contract while storage is temporarily unavailable. The document disappears from the wedding, but its cleanup job remains pending. Background attempts use the same file identity. After repeated failures the job requires review rather than disappearing from the queue.

The workspace owner can open Operations → File deletion recovery, inspect the filename, attempts and recorded error, and choose Retry cleanup. A legacy storage-credential problem must be fixed using the original storage account before that retry can succeed. Repeated deletion is safe for an object that was already removed but whose confirmation did not reach the app.

Cleanup records are scoped to their workspace. Full-access operators can remove an authorized wedding document; integration settings and manual cleanup recovery are owner controls. A failed cleanup record is not a backup of the file contents. Keep your own archival copy when you still need the original document.