>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3620124. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !35 >>> <h3>Problem/Motivation</h3> <p>ChainArchiver is 4,247 lines across 60 methods, 23 of them public, behind 11 constructor arguments. That is one class holding about 15 percent of the module's production code, and it is not one responsibility taken to an extreme; it is roughly six sitting in one file.</p> <p>What it currently owns: minting bare segments and ensuring coverage; writing the NDJSON archive and verifying it; the three purge stages (transient, live, file); segment delete and chain delete; compaction of file-purged runs; restore and disaster-recovery import; archive path construction; the three HMAC computations (identity, archive content, lifecycle); NDJSON envelope building and row replay; and the segment reads that both admin listings render from.</p> <p>The size is not the argument on its own. The argument is that the size already produced a defect. The pre-release audit found the segments listing issuing one COUNT and three secret loads per row, and the reason it was there rather than in a reader is that buildSegmentRow(), which exists to render a table, sits in the same class as the archiving machinery and inherited its per-row habits. The chains listing had the same defect and lost it in #3619114 when the chain reads moved to ChainRepository. The segments listing had no such owner to move to.</p> <p>Two further symptoms worth naming. Every test that wants a stubbed writer has to hand-build the class with all 11 arguments, so a constructor change is a change to the test suite. And a reader looking for the rule that decides one lifecycle stage has to scroll past five others to find it.</p> <h3>Proposed resolution</h3> <p>Split along the seams the class already has internally, in separate commits so each is reviewable on its own. The pre-release audit issue #3620118 took the first slice off already, moving the web-accessible-directory decision to Archive\DirectoryChecker, which is the shape the rest can follow.</p> <ul> <li><strong>A segment reader.</strong> loadSegment(), listSegments(), buildSegmentRow(), readSegmentRow(), loadSegmentRow() and the secret resolution behind them. This is the one with a defect attached, and it is what gives the segments listing somewhere to put a plural query, the way ChainRepository did for the chains listing.</li> <li><strong>A path and layout helper.</strong> getSegmentArchivePath(), buildSegmentArchivePath(), ensureArchiveSubdir(), getArchiveDirectory(), resolveDirectory() and pruneEmptyParents(). Pure apart from the directory preparation, and the natural home for the filename pattern that this audit found documented wrong in seven places.</li> <li><strong>An envelope reader and writer.</strong> writeNdjson(), buildEnvelopeLine(), buildEnvelopeRowLine(), isArchiveRecordLine(), appendArchiveRecordFooter(), readArchiveRecordFooter(), replayRows() and replayArchivedRows(). The NDJSON wire format is a contract with files already on WORM storage, so having it in one place is worth more here than in most modules.</li> <li><strong>The lifecycle operations.</strong> What remains: the stage transitions, their locking, and the chain events they emit.</li> </ul> <p>The three HMAC computations are already static and self-contained; they can move to whichever piece signs with them, or to a signing helper of their own if that reads better once the rest has moved.</p> <h3>Remaining tasks</h3> <p>Decide whether the pieces are services or collaborators constructed by the operations class. Services keep the test seams that already exist; collaborators keep the number of container entries down. The listing surfaces argue for services, since a controller should be able to ask the reader without holding the archiver.</p> <h3>User interface changes</h3> <p>None. This is a rearrangement, not a behavior change; the existing kernel coverage is the check.</p> <h3>API changes</h3> <p>ChainArchiver's public methods move to other classes. Nothing outside the module calls them: the consumer surface is AuditTrailInterface and AuditTrailSubject, and neither is involved. The bundled submodules and the drush commands are in-tree and move with it.</p> <h3>Data model changes</h3> <p>None. No schema change, no update hook, no change to the signed payload or to the NDJSON format on disk.</p> <p>AI-Generated: Yes (Claude Code was used to audit the module and to help draft this issue summary. I reviewed it before posting; there is no code on this issue yet.)</p>