## Problem Twenty-one columns across this module's five tables are declared as if they could hold any Unicode character, and none of them can. Two more, `audit_trail.context_transient_hash` and `audit_trail_outbox.content_hash`, are already declared `varchar_ascii`, so the precedent is in the file already; this is about making the rest of the schema consistent with it. A `varchar` column carries a character set. On disk that costs nothing: a `varchar` stores the bytes it uses, in the table and in the index alike, because InnoDB writes a B-tree record with the actual bytes rather than the reserved width. What the declaration does decide is InnoDB's 3072-byte index key limit, which is computed from *maximum* widths, and the cost of every comparison, since `ascii_general_ci` is a simpler collation than `utf8mb4_0900_ai_ci`. A `varchar(64)` counts 256 bytes toward that limit under `utf8mb4` and 64 under `ascii`. ### `chain`, in every table | Table | Column | Part of | | --- | --- | --- | | `audit_trail` | `chain` | unique key `chain_previous_hash`, index `chain` | | `audit_trail_checkpoint` | `chain` | index `chain_lookup` | | `audit_trail_acknowledgment` | `chain` | index `chain_range` | | `audit_trail_segment` | `chain` | unique key `chain_range` | | `audit_trail_outbox` | `chain` | - | `chain` is a machine name by construction rather than by convention. `ChainRegistry::resolve()` answers with an `AuditTrailChainInterface` out of the loaded chains or with NULL, and both write paths pass its id: `AuditTrail.php` at `chain: (string) $chain->id()` and `Logger/AuditTrailLogger.php` at `$chain_id = (string) $chain->id()`. A caller naming a chain that does not exist gets NULL and no row at all, so no word of a caller's ever reaches this column. What is stored is a config entity id, typed `machine_name` in `audit_trail.schema.yml`, which core constrains to `/^[a-z0-9_]+$/`. ### The hex digests Every one is a 64-character hex SHA-256 or HMAC-SHA256, produced here, stored as `varchar(64)`: | Table | Columns | | --- | --- | | `audit_trail` | `hash`, `previous_hash`, `hmac` (and `context_transient_hash`, already ASCII) | | `audit_trail_checkpoint` | `last_hash`, `hmac` | | `audit_trail_acknowledgment` | `anchor_before`, `anchor_after` | | `audit_trail_segment` | `hmac`, `anchor_before`, `anchor_after`, `spine`, `archive_hmac`, `lifecycle_hmac`, `file_sha256` | `audit_trail.previous_hash` is the one that sits in a key: the unique key `chain_previous_hash` pairs it with `chain`, so that key reserves 512 bytes of the index key limit where 128 would do. ### `channel`, in `audit_trail` and `audit_trail_outbox` This one is on a different footing and worth being exact about, because the first draft of this issue was not. Nothing mints a channel: it is whatever string reached `\Drupal::logger()` or `AuditTrailInterface::record()`, and the interface documents the `<module>.<subsystem>` shape as a convention. It is declared ASCII because **the module requires ASCII channel names**, which is the requirement core already makes with the same column type on `dblog.type`, and like core the requirement is left to the database rather than checked on every write. So it holds on MySQL and is not enforced on SQLite or PostgreSQL, where `varchar_ascii` is a plain `varchar`. Where this module differs from dblog is what breaking it costs, and that is documented on `record()` because a caller cannot find it out any other way: `record()` deliberately does not catch a failed chain write, so on MySQL a non-ASCII channel throws into the operation being audited and can abort the save it was recording, where dblog only loses a log line. The PSR-3 ingress is the dblog case, since `Logger\AuditTrailLogger` catches and reports a dropped event. No validation code comes with this. Core does not check its own channel column either, and a guard would refuse on PostgreSQL what PostgreSQL stores happily. This module writes its own schema in `audit_trail.install`, so the change is `varchar_ascii` in place of `varchar` on those columns: there is no field type in the way. ## What is deliberately left alone `action`, `resource` and `correlation_id`, in both tables that have them, are the caller's words under no such requirement. `correlation_id` is documented as an "opaque caller-provided id", and a caller correlating by a business reference, which is exactly what orchestra's correlation key is for, can hand over one that carries an accent. An ASCII column answers a value it cannot hold with a failed insert, and losing the audit row over it is worse than a wide column by a long way: a trail that declines to record because an id carried an accent has failed at the one thing it is for. That is narrower than the same change in pdv (#3620286), and deliberately: there every value was either produced by the module or refused upstream before it reached the column. ## Upgrading The narrower columns reach a site installing audit_trail now. An existing site keeps what it has: changing a populated column is a separate question and is not attempted here. AI-Generated: Yes (Claude Code was used to help draft this issue summary. The columns, lengths and indexes named here were read out of `audit_trail.install`, the write paths were traced to the call sites named above, and the index-size and comparison-cost claims were measured against MySQL 8 rather than reasoned about.)