Interface PurgeExpiredRunsOptions

When set, each purged run's R2 artifacts are deleted WITH its snapshot row. Hosts that store artifacts must wire this: the snapshot row is the only enumerable record of a run's artifact keys (R2 keys lead with workflowId — there is no run-level listing without it), so a retention purge without this pairing strands the run's artifacts until the deployment itself is decommissioned.

Runs processed per call. Artifact-paired path: default 100 — the purge duty's subrequest-budget guard, same batching as any batched reaper. Each run costs ~2+N subrequests (R2 list, per-artifact deletes, its row's DELETE), so an UNBOUNDED first backlog would blow the Workers per-invocation cap mid-pass and log an error every firing until it drained; size this to your plan's budget instead. Row-only path: default 1000 — one LIMIT-batched DELETE statement per firing, bounding D1 per-query cost instead of subrequests. Both paths use the shrinking eligible set as the cursor — the next firing resumes at the survivors.

Clock override for tests.

Deployment-local resource-owner table. When supplied, each snapshot delete and its run-owner release commit in the same D1 transaction. The composed Flowsafe Worker always supplies this; lower-level callers without the resource registry omit it.

The start-reservation table (flowsafe_start_idempotency). When supplied, this purge is also what keeps idempotency keys finite.

Wired the same way resourceOwnerTable is — by name, from the composed Flowsafe Worker — for the same reason: this module owns the SQL of run retention, and a reservation must be reaped in the same transaction that removes the run it points at, never by a second sweep that could interleave with it.

How long a spent idempotency key stays answerable after its run settled — the KEY-VALIDITY HORIZON, and the only tuning decision this feature has.

Until it elapses, a retry of a completed run is told ALREADY_SETTLED. After it, the reservation is gone and the same key reads as brand new, so a retry would START A SECOND RUN. That is the whole reason this exists as its own knob rather than riding ttlMs: a host whose callers retry for longer than its run retention (an overnight batch re-run, a queue with a multi-day redrive) needs keys to outlive summaries, and a host whose keys are minted per HTTP request does not.

DEFAULTS TO ttlMs, and is floored at it: a reservation shorter-lived than the snapshot it guards would be deleted while its run is still readable, and the very next retry would mint a fresh run alongside the live one — the exact double-execution this feature exists to prevent. A caller asking for less gets ttlMs, silently, because there is no configuration in which the smaller number is what anybody meant.

Must satisfy and match createD1Storage's max-39 tablePrefix contract.

workflowOutputTTL: runs untouched for longer than this are eligible.