## Problem The outbox is the **default** deferred write mode. Two sibling methods in it disagree about how a staged row is identified, and the guessing one is on the write path. `AuditTrailChainWriter::chainBuffered()` groups the staged writes per chain (`$by_chain[$write->chain][] = $write;`) and catches `\Throwable` **per group**, so the `$chained` list it returns accumulates in chain-grouped order, not staging order. It then calls `$buffer->forget($chained)`. `OutboxPendingWriteBuffer::forget()` throws that list's identity away: ```php $ids = array_slice(array_keys($this->pending), 0, count($writes)); ``` Its own comment states the false premise out loud: "The flush chains in staging order and stops at the first failure, so what it chained is the first count($writes) of what it was given." That is true per chain and false for the batch. ## What happens Staged order `A1, B1, A2, B2` as outbox ids 1 to 4, with chain A's group throwing: `$chained = [B1, B2]`, `count = 2`, so ids **1 and 2** are deleted. Id 1 is **A1, which never reached the chain**, and id 4 (**B2, which did**) stays staged for cron. So A1 is gone from the durable buffer with no row in `audit_trail`, which is the exact loss the outbox exists to prevent, and B2 is chained a second time by `flushOutboxBacklog()`, giving two attested rows for one event. Both duplicates verify, because they carry different `previous_hash` values and the `chain_previous_hash` unique key does not catch them. The operator report names the chain that failed, not the row that was destroyed. This is not a corner case: four chains ship in `config/install` (`default`, `audit_trail_entity`, `audit_trail_file`, `audit_trail_user_auth`), so one request that touches an entity and a file inside a transaction stages two chains routinely. Multi-chain staging is what `$by_chain` exists for. ## Findings in this issue - **H1** `src/Writer/OutboxPendingWriteBuffer.php:134-152`: `forget()` identifies chained rows by position while its caller returns them chain-major. `discardSince()`, twelve lines below at :165-180, selects by identity and is correct. - **H2** `src/Writer/AuditTrailChainWriter.php`: a partly-failed batch reports nothing as chained, so cron re-chains the rows that already landed. - **M4** `src/Writer/OutboxPendingWriteBuffer.php`: `takeBacklog()` has no lease, so cron takes outbox rows a live request still owns. - finding `src/Writer/AuditTrailChainWriter.php`: drops on the deferred flush path are never counted, so the operator gets no signal that anything was lost. - finding `src/Writer/AuditTrailChainWriter.php`: a 5-second lock lease against a 30-second TTL, with the key read *inside* the critical section. ## Proposed fix Make `forget()` take the rows' identities, exactly as `discardSince()` already does. The correct implementation is twelve lines below the broken one. Then: - return the landed prefix from a partly-failed batch, so cron re-chains only what did not land; - take a lease in `takeBacklog()` so cron and a live request cannot both own a row; - count and log deferred-flush drops; - read the key before entering the critical section, and align the lease with the TTL. The test must be seen to fail without the fix: stage two chains, make one throw, and assert that every unchained row is still staged and every chained row is gone. ## Also in this issue: the savepoint marker The same mistake in the other half of the buffer API, found while fixing the above and fixed with it because it has the same cause: a handle or a marker means nothing without knowing which buffer issued it. `markPendingWrites()` and `discardPendingWritesSince()` each resolved their buffer from `in_transaction_write_mode`, once per call. A setting saved between the two therefore handed one buffer's marker to the other, and the two number their handles from unrelated sources: the memory buffer counts from one per request, the outbox uses the table's serial. On a site that has been running a while every outbox id sits above any per-request counter, so a memory marker spent on the outbox discards every row the request had staged rather than the one the savepoint covered. The flush path already refuses to trust the setting this way, and says why: it drains whichever buffers exist rather than whichever the setting names, to cover the case where the value changed after something had already been staged. One path was hardened against exactly the case its sibling ignored. Reaching it needs the setting saved mid-request by a caller that also uses savepoints, so this is latent rather than live. The consequence if reached is the difference between discarding one entry and discarding all of them. The fix is to remember the buffer that issued the marker and spend it there. That adds no work to either path: the mark gains one property write, and the discard reaches for the remembered buffer first, which skips a config read rather than adding one. --- Found by a full-tree audit of `1.x` pinned at `7bae553` (tag `1.0.0-alpha9`), reading all 271 tracked files. Every claim above was checked against the source, and where a claim could only be settled by running something, the issue says so. AI-Generated: Yes (Claude Code was used to help draft this issue summary. I reviewed it before posting.)