Skip to main content

Module retry

Module retry 

Source
Expand description

SERIALIZABLE retry helper for SQLite per RFC-023 §4.3.

Mirrors ff-backend-postgres::operator::retry_serializable: up to MAX_ATTEMPTS iterations of the closure, re-running when the returned error classifies as a transient busy-contention fault (SQLITE_BUSY / SQLITE_BUSY_TIMEOUT / SQLITE_LOCKED). All non-retryable kinds (SQLITE_CORRUPT, SQLITE_FULL, misuse, etc.) propagate immediately.

Backoff shape matches the PG reference (5ms * 2^attempt) — 5ms, 10ms between the three attempts. Deliberately short: under the single-writer envelope §4.1 targets, busy contention resolves in tens of milliseconds at most, and the caller already absorbed the SQLite driver’s per-statement busy-wait budget before the error surfaced here.

Wired into Wave-9 SERIALIZABLE ops in Phase 2a.2 / 2a.3: cancel_flow, cancel_flow_header, ack_cancel_member, change_priority, replay_execution, complete_attempt, fail_attempt, deliver_signal, plus the scanner-supervisor’s budget-reconcile path.

Constants§

MAX_ATTEMPTS
Retry budget paralleling ff-backend-postgres::operator::MAX_ATTEMPTS and CANCEL_FLOW_MAX_ATTEMPTS (RFC-023 §4.3 / RFC §4.2 template).

Traits§

IsRetryableBusy
Trait letting the retry helper classify an arbitrary error type as retryable. Implemented for sqlx::Error out of the box.

Functions§

retry_serializable
Runs f up to MAX_ATTEMPTS times, retrying when the error classifies as transient busy contention. Between retries, sleeps 5ms * 2^attempt to match the PG reference shape.