## Problem `SegmentRestorer::importFromFile()` will create a segment whose range overlaps a segment the chain already has. Only an exact duplicate is refused. Measured: four rows on `webdav`, archived as one segment, that segment then widened, and the same archive file imported again: ``` import ACCEPTED overlapping range, new segment #7 ``` ## Why it is wrong `ChainArchiver::assertNoSegmentOverlap()` exists to make that state unreachable, and its docblock says what it costs: > A live-purge deletes rows by range, so purging one segment empties its overlapping siblings too, and what that leaves is a segment naming rows that no longer exist. It cannot be archived, because the file would start at the first survivor rather than at the range's signed `anchor_before`, and this module's own import reads such a file as tampered. Because every later retention stage is reached through the archive, the rows it still holds are then never purged: the operator's retention policy quietly stops applying to them. The same docblock names the producers it has checked, and asserts this one is already covered: > and `importFromFile()` refuses a range that is not wholly absent, in its own words, "to keep the operator's intent unambiguous". That phrase is `restoreSegment()`'s, and it is about `audit_trail` rows rather than about segments. What `importFromFile()` actually asks is a single equality: ```php $existing_id = $this->database->select('audit_trail_segment', 'a') ->fields('a', ['id']) ->condition('chain', $chain) ->condition('from_id', $from_id) ->condition('to_id', $to_id) ``` An exact re-import is refused; every other overlap is accepted. The `(chain, from_id, to_id)` unique key behind it answers the same narrow question, so nothing downstream catches it either. Import is the disaster-recovery path, which is where this is most likely to be reached: an operator bringing a file back from WORM storage onto a site whose segment table was rebuilt, or restored from a backup taken at a different point in the lifecycle, is exactly the operator who ends up with two segments over one range. ## The change The import asks the same question the declare path asks, from the same place. `findSegmentOverlapping()` moves to `Segment\SegmentReader`, which both writers already inject, so the rule has one home; the import refuses on a hit and names the segment already covering the range and its bounds. It is asked under the chain-write lock the import already takes, alongside the write, rather than before it: a bare segment can be declared between an unlocked check and the insert. Probed at every shape a range can overlap in, partial either side, contained, containing and exact, and at both disjoint neighbours: it refuses the five and accepts the two. The exact-duplicate message stays and is still reached first. It tells the operator to use Restore on the record they already have, which is a different and better answer than "this overlaps something". The reason the two refusals give is one sentence in one place, `SegmentReader::OVERLAP_CONSEQUENCE`. Two messages explaining what two segments over one row do to each other, in two wordings with nothing keeping them in step, is the same drift one layer up from the one this issue is about. Each door keeps its own opening and its own remedy. And the import now has a remedy to give. It said "resolve segment #N first" where the declare path names the two things an operator can actually do, on the path where they are most likely to meet the refusal: delete the segment if it is still bare, or use its own Restore action if it is the record they wanted back. ## User interface changes The archive-import form reports the refusal with the id and range of the segment already covering it, and with the two ways to resolve it. --- 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.)