GDPR Data Deletion Processor
GDPR Data Deletion Processor
The GDPR Data Deletion Processor is a nightly batch workflow that automatically fulfils data deletion requests ("right to erasure" / Article 17 GDPR) without any manual intervention. It runs every night at 01:00 UTC.
Overview
When a user submits a data deletion request, a record is inserted into the data_deletion_requests table with status = 'pending' and a scheduledFor timestamp. The nightly processor picks up all eligible requests and drives them through a safe, auditable lifecycle to completion.
Request Lifecycle
pending → processing → completed
↘ failed
| Status | Meaning |
|---|---|
pending | Request received; not yet due or not yet processed. |
processing | Actively being executed. Prevents duplicate runs. |
completed | All data deleted; confirmation email sent to user. |
failed | An error occurred during deletion. Error is preserved for audit. |
Workflow Steps
1. Eligibility Sweep
The processor queries data_deletion_requests for all rows matching:
status = 'pending'
AND scheduledFor <= NOW()
Only requests whose scheduled date has passed are actioned, allowing for configurable cooling-off periods.
2. Lock Request
Before any destructive work begins the row is updated to status = 'processing'. This acts as an optimistic lock, ensuring the same request cannot be picked up by a concurrent run.
3. Execute Deletion
executeUserDeletion(userId) is called for each eligible request. It removes or anonymises data across all platform entities associated with that user:
users— core account and profile dataprojects— all projects owned by the userpipeline_runs— CI/CD and agent pipeline historyfeatures— feature records attributed to the userreleases— release records attributed to the user
4. Mark Outcome
- On success:
statusis set tocompleted. - On error:
statusis set tofailedand the error detail is captured for audit and review.
5. Confirmation Email
Once a request reaches completed, a confirmation email is dispatched to the data subject via Resend, providing proof that their erasure request has been fulfilled.
Schedule
| Property | Value |
|---|---|
| Trigger | Cron — 0 1 * * * |
| Runs at | 01:00 UTC, every day |
| Type | nightly_batch |
Audit & Failure Handling
- Failed requests remain in the
data_deletion_requeststable withstatus = 'failed'so they can be inspected and retried. - The
processingstatus acts as a guard against double-processing; if a run crashes mid-flight the status staysprocessingand will not be re-picked by subsequent sweeps until manually reviewed. - All state transitions are recorded, providing a full audit trail for compliance purposes.