## Problem Three defects on the one path that must not fail, plus the budget it spends. ### The channel is the only unbounded string written into a `varchar(64)` column `AuditTrailChainWriter::write()` bounds `action` (64), `resource` (255) and `correlation_id` (128) with `mb_substr`, and both `AuditTrailChainWriterInterface` and `AuditTrailInterface` document the truncation. `channel` is written straight through into `audit_trail.channel`, which is `varchar(64)`. A PSR-3 channel name over 64 characters makes the INSERT fail under Drupal's default MySQL strict mode: on the PSR-3 ingress the entry is dropped and reported, on `record()` the throw reaches the host operation and can abort the save it was recording. Core's own `Drupal\dblog\Logger\DbLog::log()` truncates the channel to 64 for the same column width, so core's shape says bound it. ### A chain id can be longer than every column that stores it `config/schema/audit_trail.schema.yml` types `audit_trail.chain.*.id` as core's `machine_name`, which constrains length to 166 (`ConfigEntityStorage::MAX_ID_LENGTH`). Five columns store that id and every one of them is `varchar(64)`: `audit_trail.chain`, `audit_trail_outbox.chain`, `audit_trail_checkpoint.chain`, `audit_trail_acknowledgment.chain`, `audit_trail_segment.chain`. An id of 65+ characters therefore makes every write to that chain throw. `channels` has the same gap against `audit_trail.channel`. Reachable by config import or recipe, which is the path the file's own header comment names as the one it is guarding ("a typo arriving by import or recipe"). ### The writer defines the signed column set a second time `Chain\ChainPayload` exists so the hashed column set is "defined once, here" (its class docblock), and its `COLUMNS` const is the completeness check every reader goes through. `AuditTrailChainWriter::signAndInsert()` builds the same ten columns by hand and reaches the canonical by `unset()`ing the two that `ChainPayload` already excludes. The two definitions have to stay in lockstep: adding a signed column to `ChainPayload::COLUMNS` alone leaves every newly written row hashing over the old set, and adding it to the writer alone makes every reader report the row as tampered. ### The post-transaction flush spends the operator lock budget on a page request `AuditTrailChainWriter::chainBatch()` takes the chain lock with `ChainWriteLock::acquireWithDeadline()`, whose `CHAIN_WRITE_LOCK_DEADLINE_S` is **60 seconds** and which is documented as "tuned for operator-driven paths (drush commands, admin forms, cron lifecycle ops)". That call is reached from `flush()`, which core runs from `TransactionManagerBase::purge()` when the caller's transaction object goes out of scope — inside the ordinary web request that saved the entity. So on a chain under write contention an end-user save can block for up to a minute, while the inline path in the same class (`acquireChainLockOrThrow()`) gives up after 5 seconds and counts the drop. `MultiChainFlushTest` already records the cost from the other side: its lock double has to *throw* rather than return FALSE, because "`acquireWithDeadline()` answers a refusal by retrying until its 60-second patience budget elapses, and a test may not spend a minute of wall clock to observe it". The outbox exists so an unflushed entry is finished by cron (`flushOutboxBacklog()`), so the page path has no reason to hold the operator budget. ## Proposed resolution - Bound `channel` with `mb_substr(…, 0, 64)` alongside the three the writer already bounds. - Add `Length: max: 64` to `audit_trail.chain.*.id` and to the `channels` sequence item. - Feed the writer's own column array through `ChainPayload::createFromRow()`, which already produces exactly the canonical shape with the same casts, and drop both `unset()`s. - Give the flush its own short acquire budget, so a contended chain leaves the entry staged for cron instead of holding the response. ## Remaining tasks - [x] Bound the channel - [x] Constrain the chain id and the channel names in config - [x] One definition of the signed column set - [x] Bound the flush's lock wait - [x] Say what the shorter flush costs a `memory` entry - [x] Tests for each AI-Generated: Yes (Claude Code was used to audit the module, to draft this issue and to write the fix and its tests. I reviewed all of it, and every defect it reports is pinned by a test.)