LGPD Deletion Request Purge Scheduling Automation: Confirmed, and Never Actually Scheduled

Replying to a request with a specific, confident confirmation — "scheduled for 30 days from now" — is exactly the right thing to tell someone who has just exercised a real right. The entire truth of that confirmation depends on a SEPARATE, later process — here, an independent purge job checking on its own schedule — being able to actually find the specific record the confirmation was about, using whatever data was actually saved at the moment of the original request. A confirmation message computed and returned to a caller, and a database write persisting the state that confirmation describes, are two genuinely separate steps — and a system can get the FIRST one completely right, in isolation, while never actually performing the second one at all, with nothing in the response itself revealing the gap.

Centriu Oracle handles a data subject's request to delete a project's data by first soft-archiving it — setting its phase to paused, taking it out of any active workflow — and, per the function's own documented design, is meant to separately persist the INTENT to delete: a flag marking the deletion as pending, and the specific date, 30 days out, by which the deletion should actually be carried out. That persisted intent exists specifically because the actual, permanent deletion does not happen inside this function at all — it is handled by a completely separate process, run on its own schedule (a cron job or a manual operations review), whose own logic selects every project where the pending-deletion flag is set AND the scheduled date has already passed.

Before this fix, the function's own code comment described exactly this design — persisting the pending flag and the scheduled date specifically for that later purge process to find. The actual database update that ran, immediately below that comment, wrote only `{ phase: "pausado" }` — the project's phase, and nothing else. Neither the pending-deletion flag nor the scheduled deletion date was included in that write at all. Separately, a few lines further down in the same function, a 30-day date WAS computed — `const scheduled = new Date(); scheduled.setDate(scheduled.getDate() + 30)` — and returned to the caller as part of a confident response: `{ archived: true, deletionScheduledAt: scheduled.toISOString() }`. Because this calculation happened AFTER the database update had already run and already completed, the computed date was never in scope to be included in that write, regardless of what the write itself contained — the caller received a specific, correctly-formatted 30-day date, and the database never recorded that date, or any indication a deletion was pending, anywhere at all.

The practical consequence: a data subject exercising a real right under Brazil's LGPD to have their project's data deleted would receive an entirely plausible, specific confirmation — their project archived, a deletion scheduled 30 days out — while the system's own separate purge process, which finds its work specifically by querying for the pending-deletion flag and an elapsed scheduled date, would never once find this project, because neither of the two fields its query depends on was ever actually set. The request was genuinely, permanently pending, in the sense that nothing about it had been forgotten or lost — but it was pending in a place no running process was ever configured to look, indefinitely, unless a person happened to separately notice and manually intervene.

The fix reorders and completes the write. The 30-day scheduled date is now computed FIRST, before any database write runs, so it is genuinely available to be persisted rather than computed too late to matter. The database update is expanded from the single `phase` field to include `pending_lgpd_deletion: true`, `deletion_requested_at` (the current timestamp, recording exactly when the request itself was made), and `deletion_scheduled_at` (the real, computed 30-day date) — all three written together, in the same single update that already archives the project's phase, rather than the deletion intent being described only in a comment while never actually reaching the database. The function's own return value is unchanged in shape, but now reports a schedule that the database genuinely, verifiably reflects — the same value returned to the caller is the exact value the system's own separate purge process will later use to find and complete the request.

Before the fix, a data subject requesting deletion of their project's data inside Centriu Oracle would receive a specific, confident confirmation: "archived, scheduled for deletion in 30 days." The project's phase genuinely changed. The two fields the system's own separate purge process actually queries for — a pending-deletion flag and a scheduled date — were never written at all, meaning that process, running on its own schedule weeks later, would find nothing to act on for this specific project, silently, indefinitely, with no error anywhere. After the fix, the identical request persists both fields in the same write, and the purge process genuinely finds and completes the deletion once the real, persisted 30-day date has passed.

Centriu Oracle's project-deletion request now persists a genuine, findable pending-deletion flag and scheduled date in the same database write that archives the project, closing a gap where a data subject's confirmed deletion request could be permanently invisible to the system's own separate, independently-scheduled purge process — confirmed to the requester, but never actually queued for the follow-through step that would complete it.

This automation governs Centriu Oracle's own internal LGPD project-deletion-request handling specifically — it does not change the 30-day retention window itself, which remains the module's own documented policy, and it does not change how the SEPARATE purge process that ultimately performs the deletion is scheduled or run; this fix ensures that process has the data it needs to find a genuine request in the first place.

Documenting an intended design in a code comment — persist a flag, persist a date, so a later process can find it — is valuable and correct as documentation of INTENT. It is not, on its own, a substitute for the actual database write matching that intent, and a comment describing behavior the code beneath it does not actually perform is arguably more dangerous than no comment at all, because it can read as confirmation the behavior exists to anyone reviewing the code without independently checking the database. Persisting the real fields the comment describes, in the same write the comment sits above, closes the gap between what the code claims to do and what it verifiably does.