>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3591949. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !11 >>> <h2>Problem</h2> <p>The cron coverage pass (<code>CronArchiveHook::coveragePass()</code>) groups orphan rows past the configured cutoff into closed time buckets and passes each bucket's <code>[from_id, to_id]</code> envelope to <code>ChainArchiver::ensureSegmentCoverage()</code>. When the envelope straddles an existing segment, <code>uncoveredRanges()</code> slices it around the obstacle. Each gap is then materialised via <code>createBareSegment()</code>, which calls <code>readRowHash(chain, to_id)</code> to compute the segment's <code>anchor_after</code>.</p> <p>The slice boundary <code>min(obstacle.from_id - 1, envelope.to_id)</code> is computed in absolute <code>audit_trail.id</code> space. When that boundary id corresponds to a row on a different chain (audit_trail's PRIMARY KEY is shared across chains, so neighbouring ids commonly belong to different chains), <code>readRowHash()</code> finds no row on the target chain at that id and throws:</p> <pre>Cannot resolve anchor_after: chain "[chain]" has no row id=[N].</pre><p>coveragePass catches the throw, logs a watchdog warning, and continues. The bucket is never minted. Subsequent cron ticks repeat the same failure forever; the orphan rows accumulate on the chain indefinitely.</p> <h2>Reproduction (observed in a real install)</h2> <ul> <li>Chain <code>audit_trail_user_auth</code> has segments at <code>[1803, 1803]</code> (segment 148) and <code>[1848, 1848]</code> (segment 153), typical single-row attestation segments produced by coverage minting on neighbouring time buckets.</li> <li>Lifecycle attestations (segment_archived, segment_live_purged, segment_file_purged, segment_restored) accumulated on the user_auth chain at <code>audit_trail.id</code> values 1830, 1831, 1832, 1833 (between segments 148 and 153) and 1863, 1864, 1865, 1866 (between segments 153 and 172).</li> <li>Hourly granularity, <code>transient_purge_after = PT1H</code>.</li> </ul> <p>coveragePass groups orphan rows 1830-1833 + 1863-1866 in the same hour bucket envelope <code>[1830, 1866]</code>. <code>uncoveredRanges([1830, 1866], [{1848, 1848}])</code> returns <code>[[1830, 1847], [1849, 1866]]</code>. <code>createBareSegment(user_auth, 1830, 1847)</code> fails because user_auth has no row at id=1847 (that id belongs to a different chain).</p> <p>The watchdog log fills with recurring entries every cron tick:</p> <pre>Auto coverage failed on chain "audit_trail_user_auth" bucket 2026-05-24T17 (rows 1830-1866): Cannot resolve anchor_after: chain "audit_trail_user_auth" has no row id=1847.</pre><h2>Root cause</h2> <p><code>uncoveredRanges()</code> at <code>src/Archive/ChainArchiver.php:669</code> works in absolute id space and assumes any id in the resulting gap range corresponds to a row on the target chain. <code>createBareSegment()</code> at <code>src/Archive/ChainArchiver.php:1070</code> then resolves <code>anchor_after</code> via <code>readRowHash(chain, to_id)</code> which requires an exact-match row on the chain.</p> <p>The gap slice's <code>to_id</code> (and similarly its <code>from_id</code>) can legitimately fall on an id that exists on another chain but not on the target chain.</p> <h2>Suggested fix</h2> <p>Snap each gap's <code>from_id</code> and <code>to_id</code> to the nearest actual chain row id within the gap range, inside <code>ensureSegmentCoverage()</code>, before calling <code>createBareSegment()</code>. One SELECT per gap retrieves the bounds:</p> <pre><pre>SELECT MIN(id), MAX(id)<br>FROM audit_trail<br>WHERE chain = :chain<br>&nbsp; AND id BETWEEN :gap_from AND :gap_to</pre></pre><p>If the gap has no chain rows, skip it (no bare segment needed -- the gap was a phantom produced by absolute-id slicing). Otherwise mint <code>createBareSegment(chain, min_id_in_gap, max_id_in_gap)</code>. Both <code>anchor_before</code> (<code>readRowPreviousHash</code> on min_id) and <code>anchor_after</code> (<code>readRowHash</code> on max_id) resolve cleanly because both ids are guaranteed to exist on the chain.</p> <p>Alternative: push the snap into <code>uncoveredRanges()</code> by making it chain-aware (extra parameters for chain id and DB connection). The wrapper at the call site is the natural place since that's where the chain id is already in scope.</p> <h2>Impact</h2> <ul> <li>Pre-existing bug, not introduced by recent MRs.</li> <li>Affects any chain that emits lifecycle attestations into id slots that fall in coverage gaps between existing segments where the gap's slice boundary on the absolute id space doesn't correspond to a row on the target chain.</li> <li>Symptom: recurring watchdog warning every cron tick; orphan rows accumulate on the chain forever; retention cron never reaches them. Breaks the "every row past retention is in a segment" invariant the architecture relies on.</li> <li>Severity: orphan rows are small chain attestations (~200 bytes each), no immediate data leak risk, but the invariant break compounds over time and prevents the chain from being fully retention-managed.</li> </ul> <h2>Tests to add</h2> <ul> <li>Coverage pass on a chain where the bucket envelope straddles an existing segment AND the slice boundary doesn't correspond to a target-chain row. Assert the bare segment is minted with the snapped bounds, not the absolute-id slice bounds.</li> <li>Coverage pass on a phantom gap (envelope slice has no target-chain rows). Assert no bare segment is minted and no error is thrown.</li> </ul>