Suppression cycles
A suppression cycle is one complete pass through the DROP obligation: download the day's work items, resolve each one against the match index, mint erasures for matched consumers, record every decision in the suppression ledger, and upload a response CSV to DROP. One scheduled cycle runs per day per integration.
Daily schedule
All DROP jobs are scheduled in Pacific Time, arranged around the DROP API's 01:00–03:00 PT maintenance window:
| Time (PT) | Job |
|---|---|
| 01:00 | Incremental backfill refreshes the match index |
| 03:15 | Suppression cycle downloads and resolves the day's work items |
| 04:15 | Completion sweep promotes finished erasures and finalizes cycles |
If the DROP API reports it is in a maintenance window, the run is deferred and automatically re-enqueued after the window closes.
Cycle lifecycle
A cycle progresses through these statuses, visible in the DROP cycles tab:
queued → running → awaiting_completion → succeeded | partially_failed
↘ failed / skipped- Queued → Running. Astralis starts the cycle — only one runs at a time per integration, see concurrency and locks — and downloads the work-item ZIP from DROP. Each list type arrives as its own CSV file.
- Running. Rows stream through the pipeline in chunks: hash lookup against the match index → status derivation → erasure request minting → suppression ledger write. Statuses
2 Exempted,4 Opted out, and5 Not foundare final as soon as they are derived and are reported to DROP within the same cycle, without waiting for any erasure to complete (unlike3 Deleted, which is held — see step 3). - Awaiting completion. Rows resolved as
3 Deletedare held — the status is only reported to DROP once the minted erasure privacy request actually completes. If any rows are held, the cycle parks inawaiting_completion. - Succeeded / Partially failed. The daily completion sweep (and a per-request completion hook) promotes held rows as their erasures finish, uploads the remainder response CSVs, and finalizes the cycle.
partially_failedindicates some files or rows could not be fully processed; the cycle detail view shows the error summary. - Failed / Skipped. A cycle fails on unrecoverable errors (invalid credentials, network failure, worker crash). It is skipped when DROP has no data for the day or when a replay supersedes it.
Status derivation
Each work item resolves to a DROP status code:
| Status | Condition |
|---|---|
5 Not found | The hash matched no consumer |
2 Exempted | A matched consumer carries the exempt flag (takes precedence over the number of matched consumers) |
4 Opted out | The hash matched 2 or more of your consumers |
3 Deleted | The hash matched exactly one non-exempt consumer |
Every decision is written to the suppression ledger — one authoritative entry per work item, with an append-only history of any later status changes and their cause (cycle, amend, or manual override).
4 Opted out is DROP's official response code for an ambiguous match. Astralis records and reports that outcome but does not create a privacy request for it.
Erasure request minting
For each 3 Deleted consumer, Astralis mints an erasure privacy request using the policy configured on the integration:
- Source is
DROP, so DROP-originated requests are distinguishable in request reporting and the request detail view shows a badge linking back to the originating cycle. - External ID is
drop:{consumer_key}, making minting idempotent — a consumer matched by several work items or repeated cycles yields one request, not many. - Re-mint window. A completed request is reused for new matches for 90 days. After 90 days, a fresh match mints a new request under an epoch-suffixed external ID (
drop:{consumer_key}:e2), so a consumer whose data reappears is deleted again.
execution.require_manual_request_approval and are approved automatically, with the audit log message "Auto-approved: DROP-sourced request". Manual review of thousands of regulator-mandated deletions per day is not practical, and the Delete Act does not allow declining them. The minted requests execute through your normal DSR graph, fanning out to every connected integration.
Completion and the 45-day SLA
The California Delete Act requires deletion within 45 days of the request reaching the broker. Astralis tracks this per cycle:
- The cycle detail view shows a days remaining countdown and the count of still-pending erasures.
- The daily completion sweep checks each held row's erasure request; completed ones are promoted to the ledger and reported to DROP in remainder CSV uploads.
- When an erasure privacy request completes, a hook attempts to finalize its cycles immediately rather than waiting for the next sweep.
- If erasures are still pending when the SLA elapses, Astralis alerts once per row and keeps polling — pending work is never force-reported or silently dropped.
Response upload
Response CSVs are uploaded to DROP with a three-tier retry strategy: transient failures (429/5xx) retry automatically with backoff, persistent failures surface on the cycle's file records (upload status and attempt count), and exhausted retries raise an operator alert. Failed uploads can be re-driven with a cycle replay.
Manual controls
From the DROP cycles tab (or the API):
- Run cycle now — trigger an on-demand cycle outside the schedule.
- Run sweep now — trigger the completion sweep across all cycles.
- Replay — re-run a finished cycle as an amend submission to DROP, correcting a previous response. A reason of at least 10 characters is required and is recorded in the audit log. Replays are idempotent and supersede the original cycle for the day.
- Download files — every cycle stores both the downloaded work-item CSV and the uploaded response CSV per list type; both can be downloaded from the cycle detail view for inspection.