Struct PurgeReport 

#[non_exhaustive]
pub struct PurgeReport {
    pub tasks_deleted: u64,
    pub orphan_rows_deleted: u64,
    pub idempotency_keys_deleted: u64,
    pub batches: u32,
    pub complete: bool,
}

What one call to purge_expired did.

#[non_exhaustive]: read its fields, do not construct or exhaustively destructure it. A sweep that learns to count something new should not be a breaking change — 0.13.0’s breaking list already carries one renamed field of this struct.

Fields (Non-exhaustive)

Non-exhaustive structs could have additional fields added in future. Therefore, non-exhaustive structs cannot be constructed in external crates using the traditional Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.

tasks_deleted: u64

Task rows deleted.

orphan_rows_deleted: u64

Side-table rows this sweep had to reclaim itself: artifact-journal rows and event-log rows whose task was deleted.

Normally zero, and that is the healthy reading: both tables have an ON DELETE CASCADE, so on a pool with foreign_keys=ON — which SqliteTaskStore::new sets — the rows go with the task and the sweep finds nothing left to do. A non-zero count means rows had outlived their task, which happens when from_pool was handed a pool without the pragma.

It is zero on PostgreSQL because nothing counts there

Only the SQLite sweep runs anti-join deletes; the PostgreSQL one has no orphan statement at all, so this field is structurally zero on both Postgres stores rather than observed to be. That is a deliberate omission and not an oversight: PostgreSQL has no per-session equivalent of foreign_keys=OFF, so a declared ON DELETE CASCADE always fires and there is nothing for a sweep to find.

The residual case it does not cover is a caller who handed from_pool a database in which task_events or tenant_task_events already existed without the foreign key — CREATE TABLE IF NOT EXISTS leaves such a table alone. Rows can then be stranded there and no Postgres sweep will reclaim them. Declare the tables from this crate’s own DDL, or from its migration runner, and the case does not arise.

Since 0.13 the SQLite sweep runs on every purge rather than only on one that deleted a task: a purge that fails part way strands rows that outlive it, and the sweep is what reclaims them.

idempotency_keys_deleted: u64

Idempotency keys deleted for being older than RetentionPolicy::idempotency_key_max_age.

Zero when that is None, and zero on a sweep that finds none expired. Unlike orphan_rows_deleted a non-zero count here is the healthy reading, not a warning: it is the sweep doing the job it was given.

batches: u32

Batches executed.

complete: bool

false when RetentionPolicy::max_batches stopped the sweep with work still to do, so a caller can tell “nothing left” from “ran out of budget” instead of inferring it from a count.

Trait Implementations

impl Clone for PurgeReport

fn clone(&self) -> PurgeReport

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Copy for PurgeReport

impl Debug for PurgeReport

fn fmt(&self, f: &mut Formatter<'_>) -> Result<(), Error>

Formats the value using the given formatter.

impl Default for PurgeReport

fn default() -> PurgeReport

Returns the “default value” for a type.

impl Eq for PurgeReport

impl PartialEq for PurgeReport

fn eq(&self, other: &PurgeReport) -> bool

Equality operator ==.

fn ne(&self, other: &Rhs) -> bool

Inequality operator !=.

impl StructuralPartialEq for PurgeReport