## Problem The lifecycle stages skip what they cannot process and carry on. `applyLifecycleOp()` catches the failure, logs one `warning` per segment per tick, and the stage moves to the next candidate. With the per-chain resume points ([#3620383](https://git.drupalcode.org/project/audit_trail/-/issues/3620383)) it now moves past them permanently until the cursor wraps, which is the point: one wall of refusals must not stop retention for a chain. Nothing counts what it stepped over. So a segment whose lifecycle signature does not validate, whose `to_created` is unstamped, or whose archive destination a crashed run left occupied, sits unprocessed indefinitely. Retention looks healthy, the settings page reports the configured schedule, the segment table keeps growing, and the only signal is a log line among thousands. This matters most at the transient-purge stage, which is the erasure stage: the context an operator asked to be kept only for a while is kept forever, and nothing on the status report says so. ## The module already answers this exact shape elsewhere `AuditTrailRequirementsHooks::checkOutboxDepth()` raises `audit_trail_outbox_abandoned` for entries the flush gave up on, and its own description says why it is separate from ordinary backlog: > These entries were accepted but could not be written to a chain after @attempts attempts, so the flush stopped retrying them and moved on to the ones behind them. That is the same skip-and-continue decision the lifecycle stages make, with the surface the lifecycle stages lack. ## Suggested fix A requirements entry counting segments overdue at a stage. It needs no re-running of the operation and no new state: a segment past its cutoff by a wide margin and still unprocessed is stuck whatever the reason. ``` archived_at = 0 AND to_created > 0 AND to_created < (cutoff - grace) transient_purged_at = 0 AND to_created > 0 AND to_created < (cutoff - grace) live_purged_at = 0 AND archived_at <> 0 AND to_created < (cutoff - grace) ``` One indexed count per chain per stage, on a report that already runs these kinds of checks. Open questions for whoever picks this up: - The grace period. Long enough that a chain merely working through a backlog under its per-tick cap never trips it, short enough to be noticed. Some multiple of the stage interval rather than a fixed span, since `archive_after` can be days or years. - One entry naming the stages, or one per stage. The outbox precedent uses one entry per distinct condition. - Severity. `audit_trail_outbox_abandoned` is an error because the trail is knowingly incomplete. A stalled erasure stage is arguably the same: the module promised to remove something and did not. - The description should name the repair, which already exists: `drush audit_trail:reindex-segments --dry-run` reports where the index and the chain disagree and rebuilding from the chain re-seals the signature, `drush audit_trail:rewrite-archive --id=N` rebuilds a missing file against its recorded digest. ## Why it is filed separately Found while auditing [#3620383](https://git.drupalcode.org/project/audit_trail/-/issues/3620383), which is what makes the silence permanent rather than eventual. That change is a contained fix to two queries with both directions tested; this is a new operator-facing surface with a threshold to choose and its own tests, so it does not belong in the same merge request. ## What to do about one that cannot be fixed Some stalls are permanent. `reindex-segments` rebuilds the index from the chain events, so it works while those events are still in the chain; once they have aged out `replaySegmentEvents()` cannot produce the row, and `SegmentIndex` deliberately refuses to remove it rather than destroy the index it was run to repair. `compareIndexToChain()` then reports it as `unexpected` and leaves it to a person. **Acknowledge, do not destroy.** A segment carrying lifecycle stamps is the evidence that a range was lawfully removed: the verifier crosses a purged gap through `walkGap()`, bridging on the segment's signed `anchor_before` / `anchor_after`. Deleting one leaves a hole nothing accounts for, the chain reads as broken from there on, and no restore brings the bridge back. A bounded problem becomes a chain-wide one. An acknowledgment is already the module's word for "this cannot be made right, here is the operator's reason", recorded as a chain event so the explanation is itself tamper-evident. It needs no new concept here: a stuck segment whose range is covered by one (`findAcknowledgmentCovering()`) should not be counted by the check above, so the report means stuck **and unexplained**, which is the distinction the verifier already draws between a broken range and an acknowledged one. Two boundaries on that: - Acknowledging a stall must not let the stage proceed. Explaining a refusal is not authorising the transition it was refusing, and `loadSegmentRowForTransition()` refuses because the transition would re-sign the stamps as found and make them permanent. That reasoning does not change because somebody wrote a note. - The one case where removal is arguable is a **bare** segment: never archived, no stamps at all, broken signature. Deleting it lets the coverage stage re-mint a fresh one over the same rows, which clears the stall. If that is ever built, the honest name for it is re-minting rather than deletion, and it must refuse the moment any lifecycle stamp is present. ## Why the count matters more than it looks [#3620383](https://git.drupalcode.org/project/audit_trail/-/issues/3620383) is what makes an unfixable segment survivable: before the resume points, one of them sat at the front of every batch and stopped retention for the whole chain forever, which was at least loud. After them the stage steps over it and everything behind it keeps moving, so the damage is bounded to that one range. The cost of that trade is silence, and this issue is the other half of it: if some stalls are permanent by design, an operator has to be able to decide that knowingly rather than discover it years later. --- AI-Generated: Yes (Claude Code was used to help investigate and draft this issue. The behaviour described was traced in `AuditTrailCronArchiveHooks::applyLifecycleOp()` and `AuditTrailRequirementsHooks::checkOutboxDepth()`.)