>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3591871. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !7 >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p><code>ChainArchiver::ensureSegmentCoverage()</code> reads the existing segments list unlocked, then INSERTs bare segments for the uncovered gaps. Two concurrent callers with <strong>different but overlapping input ranges</strong> can compute their obstacle lists before either INSERTs, producing overlapping-but-not-identical bare segments that the <code>(chain, from_id, to_id)</code> UNIQUE constraint does not catch.</p> <h3>Reachability</h3> <p>This race lived previously inside <code>transientPurgeBucket()</code>, but was much harder to hit: it required transient-purge to be configured on the chain. Issue #3591838 widened reachability by making coverage unconditional -- it now runs on every cron tick from <code>CronArchiveHook::coveragePass()</code>. Any concurrent call to <code>drush audit_trail:auto-archive</code> (which calls <code>runChainLifecycle()</code> and bypasses the per-chain cron throttle) is now enough to expose the race.</p> <h3>Steps to reproduce</h3> <p>Concurrent run on the same chain:</p> <ul> <li>Caller A (cron coveragePass): <code>ensureSegmentCoverage('webdav', 1, 30)</code> -- today's granularity bucket.</li> <li>Caller B (operator): <code>drush audit_trail:archive --chain=webdav --from=25 --to=50</code>.</li> </ul> <p>Race interleaving:</p> <ol> <li>A SELECTs obstacles in [1, 30]. Empty. Plans bare [1, 30].</li> <li>B SELECTs obstacles in [25, 50]. Still empty -- A hasn't INSERTed yet. Plans bare [25, 50].</li> <li>A calls <code>createBareSegment()</code>, INSERTs [1, 30] under the chain-write lock.</li> <li>B calls <code>createBareSegment()</code>, INSERTs [25, 50]. <strong>(from, to) differs from A so the UNIQUE constraint does not fire.</strong></li> </ol> <p>End state: two segments on chain webdav with overlapping id ranges [1, 30] and [25, 50] (overlap at ids 25-30).</p> <h3>Why the UNIQUE constraint does not save us</h3> <p>The constraint is on <code>(chain, from_id, to_id)</code>. It catches identical ranges (same-range race), not overlapping ranges. Same-range race is the safe case: both callers plan identical bares, one INSERT wins, the other throws cleanly inside <code>safelyRunPass()</code> and gets logged.</p> <h3>Downstream impact</h3> <p>Once two segments overlap, every subsequent lifecycle pass operates on inconsistent state:</p> <ul> <li>Archive may write two NDJSON files spanning overlapping ids -- one row's evidence ends up in two archives.</li> <li>Live-purge on the older segment may DELETE rows still referenced by the younger sibling.</li> <li>The verifier walks both segments but cross-references one row to a chain event from each, depending on iteration order.</li> </ul> <h3>Proposed resolution</h3> <p>Three options with tradeoffs:</p> <ol> <li><strong>Hold the chain-write lock around the entire ensureSegmentCoverage call.</strong> Atomic, simple. But the lock now spans up to <code>MAX_COVERAGE_PER_TICK = 50</code> INSERTs, blocking every user-facing audit log write on the chain for the duration.</li> <li><strong>Separate <code>audit_trail:coverage:[chain]</code> lock</strong>, distinct from the chain-write lock. Coverage holds this lock around its full SELECT+INSERT cycle; chain-row writes proceed unblocked. Two coverage callers serialize. <code>createBareSegment()</code> still takes the chain-write lock per-INSERT, so segment-row writes serialize correctly with chain-row writes. Recommended.</li> <li><strong>SELECT FOR UPDATE on the segment table for the chain.</strong> Locks just the segment rows. MySQL gap locks on missing ranges can deadlock with concurrent segment INSERTs -- needs careful testing.</li> </ol> <h3>Related</h3> <ul> <li>#3591838 (parent: the refactor that widened reachability)</li> </ul> <h3>Remaining tasks</h3> <ul> <li>Decide between options 2 and 3.</li> <li>Implement.</li> <li>Kernel test: spawn two concurrent ensureSegmentCoverage calls with overlapping ranges and assert no overlapping segments result.</li> </ul> <h3>API changes</h3> <p>None for callers. If option 2 is taken, a new internal lock name is introduced but the public API of <code>ChainArchiver</code> is unchanged.</p> <h3>Data model changes</h3> <p>None.</p>