## Problem Clearing a chain's data leaves that chain's staged entries in `audit_trail_outbox`, and the next cron run chains them straight back onto the chain that was just wiped. Measured: one chained row on `webdav`, one entry staged in the outbox for `webdav`, then `deleteChain('webdav')`, then `hook_cron`: ``` outbox rows surviving deleteChain: 1 audit_trail rows on the wiped chain after cron: 1 ``` Both confirm forms promise otherwise. `AuditTrailChainDeleteForm` says it "wipes the chain's rows, segments, acknowledgments and checkpoints"; `AuditTrailChainEntityDeleteForm` says "The chain disappears entirely." ## Why it is wrong `ChainArchiver::deleteChain()` deletes from four tables: `audit_trail`, `audit_trail_segment`, `audit_trail_acknowledgment` and `audit_trail_checkpoint`. `audit_trail_outbox` has a `chain` column and is not among them, and neither is it among the four `ChainRepository::getDataCounts()` counts for the confirm page, so the operator is not told the entries are there either. A staged entry is an ordinary state, not an edge: any audited write made inside a caller's transaction is parked there, and `OutboxPendingWriteBuffer` is the shipped default. An entry whose request died between the commit and the flush waits there for cron, which is what the outbox is for. On the entity-delete path the consequence outlives the surprise. The chain's config entity is gone, so `ChainRegistry::getActiveChains()` never returns it again and no retention stage visits it: the resurrected rows are outside transient-purge, archive, live-purge and file-purge from then on. `ChainRepository::listChains()` reads the tables rather than the entities, so the chain reappears in `verifyAll()` and on the status report, as a chain nothing is scheduled to happen to. It is also the wrong answer on its own terms. An entry staged for a chain an operator has just wiped describes work on a chain that no longer holds anything, and the chain it lands on starts again at genesis: the row is not linked to anything it was written beside. ## The change The chain's `audit_trail_outbox` rows are deleted inside `deleteChain()`, with the other four, under the same chain-write lock, and counted in `getDataCounts()` so both confirm pages say how many entries are about to go with the rest. Not a silent side effect of something else: this is the operation whose whole contract is "every trace of this chain", and the staged entries are the one part of that trace it was missing. That sweep alone does not hold cron off. `flushOutboxBacklog()` reads the backlog and then queues for the chain-write lock, which is the lock `deleteChain()` takes; a tick that read the entries a moment before the operator submitted gets the lock second and chains them onto the chain that was just wiped. The batch now asks the buffer, under the lock, which of its writes are still staged, and reports the ones it drops. Confined to that flush: the post-transaction one chains writes the same request staged microseconds earlier, and asking there would be a query on the path that has to stay cheap. Both confirmations called every staged row an entry "still waiting to be recorded". That is the status report's phrase for the half of them cron still retries, and the report keeps the other half apart deliberately, at error severity, as entries whose cause has to be fixed before they can be recorded. An operator sent to the confirmation by that error read both halves described as waiting. The count is unchanged, and has to be: the delete takes them whatever their attempts say. The same report told that operator "nothing deletes them", which this change makes false. It now names clearing or deleting the chain as the other way they leave. `audit_trail_outbox` has no index on `chain`, and its schema justified dropping the one it had with "No such query exists". Two do now, both added here. The index stays dropped, because both are human-initiated against a table a healthy site keeps near-empty while the index would be maintained on every staged write, inside the caller's transaction; the schema comment says that rather than denying the queries. ## User interface changes Both chain-deletion confirm pages gain the count of staged entries that will be removed, and neither calls them entries waiting to be recorded. The status report's abandoned-entries description names chain deletion as a way they leave. --- AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the fix and its tests. I reviewed both, and the new tests were confirmed to fail against the unpatched module and to pass with the change.)