With the jobs module enabled, a signed-in user can have their export built in
the background rather than during the request, for a subject whose zip takes
too long to stream:
-
POST /api/v1/me/export-jobs queues it (202). While one is open, asking
again returns the same job.
-
GET /api/v1/me/export-jobs/:id reports pending, running, done or
failed, and when done a download-path.
-
GET /api/v1/me/export-jobs/:id/download serves the zip for 24 hours. On S3
and GCS it redirects to a signed URL that lives five minutes; on local
storage the route sends the file.
Platform admins ask for someone else’s export the same way, at
POST /api/v1/users/:id/export-jobs and POST /api/v1/tenants/:id/export-jobs,
and follow it at the Location they get back, under /api/v1/me/export-jobs.
The export is written to the audit log (the user’s, or tenant_audit_log) when
it is asked for, because that is where the admin and their request are known.
The admin can follow the job and download it only while they are a platform admin.
Only the user who asked sees a job; to anyone else it does not exist. A user
has at most one open job per subject, even when requests race. A user may
open five an hour
(:export-requests-per-hour in :wagoe/storage, 0 for no limit); more
answer 429. The archive is streamed to a temporary file under the storage
root’s .spool/ and stored private under data-exports/; it is not an upload.
A spool left by a crash is deleted at the next boot. Jobs run on the
:default queue, or :export-queue in :wagoe/storage.
Nothing deletes old archives until you configure the
:storage/export-archives retention policy. There is no default because
retention in Wagoe is always opt-in: an upgrade must not start deleting data.
After 24 hours an archive cannot be downloaded, but it still holds personal
data, so configure the policy when you enable export jobs:
:wagoe/privacy {:retention {:storage/export-archives {:retain "P2D"}}}