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_ATTEMPTSandCANCEL_FLOW_MAX_ATTEMPTS(RFC-023 §4.3 / RFC §4.2 template).
Traits§
- IsRetryable
Busy - Trait letting the retry helper classify an arbitrary error type
as retryable. Implemented for
sqlx::Errorout of the box.
Functions§
- retry_
serializable - Runs
fup toMAX_ATTEMPTStimes, retrying when the error classifies as transient busy contention. Between retries, sleeps5ms * 2^attemptto match the PG reference shape.