## Problem Three things combine so that one staged write that can never be chained stops every later one on its chain from ever being recorded. - `chainBatch()` aborts its loop on the first write that fails, so the writes behind it in that chain's batch are never attempted. - `takeBacklog()` selects the oldest staged rows with no way to exclude a row that cannot be chained, so the next cron run re-attempts the same write first and stops in the same place. - Nothing bounds the retries. `audit_trail_outbox` records no attempt count, so a write that fails permanently is indistinguishable from one whose request has simply not been picked up yet. ## What happens Reproduced with three writes staged on one chain, the second one occupying a `(chain, previous_hash)` pair that is already taken, over three consecutive `flushOutboxBacklog()` runs: ``` run 1: chained=1 | still staged=[2,3] | in chain=[first] run 2: chained=0 | still staged=[2,3] | in chain=[first] run 3: chained=0 | still staged=[2,3] | in chain=[first] ``` The third write is valid and can never be chained. Every deferred write added to that chain afterwards joins the queue behind the second one. `takeBacklog()` orders by id and caps each run at 500 rows, so once that many rows have accumulated behind one unchainable write the window contains nothing else, and no chain's deferred writes are flushed at all. This affects only writes made inside a caller's transaction under the `outbox` mode. A write made outside a transaction is chained inline and is unaffected. An operator is warned rather than left blind: `checkOutboxDepth()` reports a climbing depth on the status report, and its description already names "recording them is failing" as one cause. What is missing is a bound on the retries, and a signal that separates "cron is not running" from "this entry can never be recorded". ## Proposed fix Add an `attempts` column to `audit_trail_outbox` and let quarantine be `attempts >= MAX_ATTEMPTS`, so one column both counts and excludes. - `takeBacklog()` gains `condition('attempts', MAX_ATTEMPTS, '<')`. - Increment only for the write the batch was actually on when it failed. A lock-acquisition failure fails the whole batch with no individual write at fault, and must blame none of them. - `MAX_ATTEMPTS > 1`, so a transient failure (a deadlock, a lock timeout, a momentarily unresolvable secret) still gets retried rather than quarantined on its first bad tick. - Split the requirement that reports this. Depth stays a warning; a quarantined row becomes an error, because it is an entry the application wrote that never entered the tamper-evident record, which is a different thing from a backlog. - Index `(attempts, id)` so the added condition does not turn the backlog query into a filtered scan once quarantined rows accumulate. The column needs no update hook. There are none before 1.0 and reinstall is the documented upgrade path, so `audit_trail.install` simply gains the field and the schema version does not move. Two consequences belong in `docs/`: - A quarantined row was never inserted into `audit_trail`, so there is no gap in the hash chain and verification stays clean. The status report is the only place this surfaces. - Once a later write on the chain has been recorded, the quarantined entry's position is gone. It can only be recorded as a new entry at the tail, and its original `created` value is preserved in the payload for that. --- Found while implementing #3620306, and reproduced with a kernel probe against `1.x`. AI-Generated: Yes (Claude Code was used to help draft this issue summary. I reviewed it before posting; there is no merge request on this issue yet.)