A user-data export or erasure request can span several systems and take longer than one HTTP response. Model it as an authorized operation with states such as accepted, checking, running, partially failed, complete, and rejected. The initial response means the request was accepted, not that an export is downloadable or erasure finished. Keep the requester, target scope, operation ID, policy version, and audit timestamps as minimal job metadata. A status endpoint must be private. Terminal success should require verified target results; a worker crash, missing connector, or unresolved exception must remain visible and retryable. Human review requirements depend on the organization’s policy and should be explicit in the job.
Export and Erasure Job State
Working case
A user asks to erase case 47 and download an account export. The API returns two job IDs. The export waits while a snapshot of permitted records is assembled; a Ready state gives a short-lived download path. The erasure job marks the case inaccessible, removes active copies, and waits for checks from search and object storage. Search cleanup fails once. The status remains Partially failed, with a retry action for an operator, instead of telling the user everything is gone. A second identical request uses the same intent identity or an explicit new request, avoiding duplicate cleanup side effects.
Implementation boundary
function completionState(targets) {
if (targets.every(item => item === "done")) return "complete";
return targets.some(item => item === "failed") ? "partial-failure" : "running";
}
console.log(completionState(["done", "failed", "done"]));
// Output: partial-failureThe function illustrates aggregation, while a real workflow records per-store attempts, retry bounds, and verified results. Authenticate the requester and authorize the target before creating the job. Separate export and erasure grants; a user may be entitled to one but not the other. Use idempotent worker steps and a stable operation ID so a lost response does not duplicate destructive actions. Avoid exposing exact private record counts to an unauthorized status caller. Choose a terminal response that reflects the approved policy and include known limitations, such as backup expiration timing, rather than claiming immediate physical erasure of every byte. Keep only the minimal completion evidence required by policy.
Cost and boundaries
A job touching k stores requires at least O(k) orchestration and verification work plus O(n) processing for n included records. Parallel cleanup reduces elapsed time but can overload downstream systems; a bounded queue and per-store retry budget contain that cost. Detailed per-item logs may expose private data and grow O(n), so aggregate evidence by store and operation where possible. An export can consume large temporary storage and must expire. Measure time to terminal state, partial-failure backlog, retry count, cleanup lag, and unauthorized status attempts.
Failure trace
The erasure endpoint returns 200 immediately after placing a queue message, and the UI says Deleted. The queue is down, so nothing was removed. Return an accepted operation state and report terminal completion only after checks. Another defect lets anyone who knows a job ID see that the user has 62 private records. Authorize status and minimize exposed metadata. If a worker repeatedly fails, retain a visible partial-failure state with an owner and next action; neither infinite silent retries nor false success meets the contract.
Verification
- An accepted response never claims the multi-store job is complete.
- Partial failure has a visible owner and retry path.
- Status and artifact access enforce requester and target scope.
Practice drill
Submit authorized export and erasure requests for case 47. Cut the queue after acceptance, then restart it; confirm stable operation IDs and no duplicate cleanup. Fail one search-index step and verify Partially failed status while reads stay gated. Request the status from another account and inspect that no private count leaks. Complete all active-store checks, download the export once through an expiring grant, and verify temporary artifact cleanup. Record how a backup restore will respect the deletion marker before declaring the full policy outcome.
Decision note
Treat export and erasure as private operations with explicit per-store evidence and honest terminal states.
Common Mistakes
- Showing Deleted when only a message was enqueued.
- Treating a job ID as authorization for status or download.
- Discarding evidence of a failed downstream cleanup step.
Connected lessons
Data Retention, Export, and Erasure; Retention Inventory and Expiry Workflows; Backup Restore with Deletion Tombstones; Browser Storage Cleanup on Account Change; Accepted Operations and Status Resources; Large Export Download and Integrity; Retention Inventory and Expiry Workflows.
Apply and check
Build Project: verified data expiry and review Web Development: authorization and data lifecycle decisions quiz.
