Purge a retired workspace
What It Does
Purge proceeds only under the recorded deletion authority and compensates forward. Each participant owns removal and inventory for its resources, and the final verification can repeat the purge round within its configured limit.
The Flow
The diagram separates the relevant success, alternative and failure paths. The numbered hop rows retain the detailed authority checks, delegated work and retry limits.
When Something Fails
Database completion precedes the external ledger write. The job can therefore fail after the request says completed. Task replay can finish the ledger, while request-specific retry requires failed state; recovery after replay exhaustion needs an explicit operator procedure.
Removal batches converge on absence and retries carry completed steps forward. A failure consequence applies only to the executing request that still names that job. Completed-request task replay can finish notices or ledger writing without reopening deletion.
Tasks recheck the named job and deleting lifecycle, with an exception for completed-request finalization replay after the workspace row is gone. Each batch commits independently; locks are not held across the entire purge.
Open Design Questions
The recorded findings retain any stronger planning expectation, missing writer or unproved recovery path. Observed behavior does not approve those outstanding product choices.