Skip to main content

run_checkpoint_task

Function run_checkpoint_task 

Source
pub async fn run_checkpoint_task(
    pool: Arc<ConnectionPool>,
    config: CheckpointConfig,
    event_store: Option<Arc<dyn EventStore>>,
    namespace: String,
    shutdown_rx: Receiver<()>,
)
Expand description

Run the WAL checkpoint background task.

This is a long-running async task that should be spawned with tokio::spawn. It loops until shutdown_rx observes a change (or its sender is dropped), at which point it exits on its next select! wakeup. Callers should hold the paired tokio::sync::watch::Sender for the daemon’s run scope and send on it as part of the shutdown sequence.

An earlier version of this task used Arc::strong_count(&pool) <= 1 as its exit condition instead of an explicit signal. That check is unreachable whenever a sibling owner holds its own clone of pool for the task’s lifetime — which the production boot path does: event_store (Option<Arc<dyn EventStore>>), when Some, is a SqlEventStore that retains its own Arc::clone of the same pool, so the task always observed strong_count == 2 and never exited via that mechanism (issue #774). The explicit watch channel does not depend on how many other owners exist.

The task issues PRAGMA wal_checkpoint(PASSIVE) on every tick — ordinary ticks stay PASSIVE-only and non-blocking; see the module-level doc for the rare Plank 2 TRUNCATE escalation checkpoint_once may additionally run under the same writer guard when WAL pressure is sustained past truncate_high_water_pages. A WARNING is emitted once on threshold crossing (wal_pages transitions from below a threshold to at/above) rather than on every tick, preventing log spam when a long-lived reader pins a WAL snapshot.

Skipped ticks (writer mutex busy) leave both crossing-state flags unchanged so that a skip cannot spuriously re-arm the rate limit while WAL pressure is still elevated.

Uses try_writer_nowait (zero-wait try-lock) so a busy writer causes the current tick to be skipped rather than stalling write traffic.

event_store (ADR-094): when Some, this task appends a best-effort CheckpointOutcomeRecorded lifecycle event on every tick where WAL pressure is at/above warn_pages, plus exactly one drain row on the tick that observes pressure fall back below warn_pages after an elevated episode — never on every ordinary below-warn tick. namespace is stamped on those rows. None makes event emission a pure no-op, exactly like an unconfigured audit sink elsewhere in the runtime.