## Problem `Writer\OutboxPendingWriteBuffer::loadBacklog()` takes the oldest staged rows filtered on `attempts` alone: ```php ->condition('attempts', self::MAX_ATTEMPTS, '<') ->orderBy('id', 'ASC') ->range(0, $limit) ``` Nothing asks how old a row is, so nothing distinguishes a row an interrupted request abandoned from one a live request is about to chain itself. That is the distinction the method exists on: `AuditTrailChainWriter::flushOutboxBacklog()` says so in its own docblock, "The post-transaction callback is the normal way a staged row gets chained; this is what happens when the process carrying that callback died first." A row is visible to cron from the moment the caller's transaction commits until its own post-transaction flush chains it. Normally that is under a millisecond. It stops being under a millisecond when the chain-write lock is contended: the request's flush then queues for up to `ChainWriteLock::CHAIN_WRITE_LOCK_REQUEST_DEADLINE_S`, five seconds, with its rows committed and unchained the whole time. Contention is the condition the outbox exists for, so the window and the load that produces it arrive together. ## What happens when cron takes one The entry is chained twice, and both copies verify. Cron re-asks `stillStaged()` once it holds the chain-write lock, so it drops a row somebody else took. The post-transaction flush does not, and deliberately: asking would put a query on every request that deferred a write, forever. So cron chains the row and deletes it, the request's flush chains it again from the copy it is holding in memory, and each copy links to a different row before it, which is exactly what the `chain_previous_hash` unique key cannot catch. `AuditTrailChainWriter::flush()` names this at the point where it decides not to ask, and says the answer belongs on the backlog read. #3620395 is the neighbouring race, a chain clear against the same flush, and its fix does not reach this one. ## Proposed change Give `loadBacklog()` a grace period, and take only rows older than it: ```php ->condition('created', $cutoff_us, '<') ``` `audit_trail_outbox.created` already holds the event time in microseconds, captured when the write happened. The cutoff wants to be safely past `CHAIN_WRITE_LOCK_REQUEST_DEADLINE_S`, because a row younger than that cannot be abandoned yet: its flush is either still queued for the lock or has only just given up. A constant, not a setting. The right value is the request deadline plus margin by construction, and an operator asked for a number here has nothing to judge it against. It costs nothing. It is a condition on a `SELECT` cron already runs, and it makes the read match what the method says it is for. `countBacklog()` takes it too. That number is the status report's "entries waiting to be recorded", described there as "left behind by a request that ended before it could record them", and a row its own request is about to chain is not one of those. On a busy site there is always one. ## What this does not change Nothing about the operator's clear. `Archive\ChainArchiver::deleteChain()` removes a chain's staged entries under the same lock, and a request's own flush can be waiting on that lock with those rows in hand whether cron exists or not. That is #3620395's to hold, and the staged-row check there stays. Nor `ChainRepository::countEntriesAwaitingChaining()`, which the two delete confirmations and the clear's refusal read. That asks what may still be chained, and a row staged a microsecond ago is exactly the row a clear has to refuse on. AI-Generated: Yes (Claude Code was used to help draft this issue summary. The query, the constants and the column were read out of the module; the double-chaining is what `AuditTrailChainWriter::flush()` documents about itself.)