## Problem Three columns hold a machine name something already guarantees, and all three are declared as plain `string` base fields, which reach the database as `utf8mb4 varchar`. | Column | What guarantees it | Indexed | | --- | --- | --- | | `kessai_payment.subject_type` | Core mints entity type ids | leads `kessai_payment__subject_account` | | `kessai_payment.kind` | `PaymentEngine::assertKind()` | no | | the movement `kind`, on `MovementBase` | `PaymentEngine::assertKind()` | no | `assertKind()` refuses anything but `[a-z0-9_]{1,64}` at every public door that takes a kind: `initiate()`, `capture()`, `recordTakenAndGivenBack()`, `refund()`, `cancel()`, and `createTokenPayment()`, through which both `authorizeToken()` and `chargeToken()` pass. Worth being explicit that the `Regex` property constraint on those fields is *not* what enforces it — nothing on those paths validates the entity, which is exactly what `assertKind()`'s own docblock says it exists for. The guard is the guarantee; the constraint covers a form. `kessai_payment.account_uuid` already carries `is_ascii` from earlier work. 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 decides 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`. So this is a small change and worth being honest about the size of it: the index is nowhere near the key limit, and the win is a cheaper comparison on a key probed by every subject-scoped lookup, plus three declarations that stop claiming something untrue about columns that are already constrained elsewhere. While here, the `account_uuid` comment justified its own `is_ascii` with "the difference between one byte per character and four in the index that leads on this column". That is not how InnoDB stores a `varchar`, and the comment is corrected in the same change. ## What is deliberately left alone - `subject_id` is an entity ID. Most are integers, but a content entity type may key on a string, and nothing constrains what that string holds. The test asserts it stays wide, so that is a decision the suite holds rather than an omission. - `consumer` is documented as opaque — "Never interpreted here" — so it is the consumer's own word. - `kessai_payment_metadata.name` and `.value` are likewise the consumer's own words, and they lead `kessai_payment_metadata__lookup`. - `state` is a `list_string` field, and `list_string` ignores `is_ascii`; only core's `string` and `string_long` honour it. An ASCII column answers a value it cannot hold with a failed write, so the line is drawn by who produces the value rather than by what the value usually looks like. Everything above is on the far side of it. ## Upgrading The narrower columns reach a site installing kessai now. An existing site keeps what it has: changing a populated column is a separate question and is not attempted here. This is one of four modules swept for the same thing: pdv #3620286, audit_trail #3620394 and orchestra [#3624476](https://www.drupal.org/project/orchestra/issues/3624476). AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the change and its test. The column descriptions, the index definition and every `assertKind()` call site named here were read out of the source, and the test was confirmed to fail without the change and pass with it.)