## Problem Two defects on one column, `kessai_payment.consumer`, which is what a payment records about whose it is and the only thing that keeps two consuming sites apart. ### It cannot hold every client id The column is `max_length: 64`. What is written into it is `ConsumerScope::getConsumerId()`, the consumer's own `client_id`, and `consumers` declares that field at `max_length: 255` and describes it as "an arbitrary unique field, like a machine name" — a value the site owner types. Every neighbouring value a caller names is bounded at the engine's door and refused with a sentence that says what the limit is: the kind by `assertKind()`, the metadata name and value by `assertMetadata()`, the amount's magnitude by `assertAmount()`, the onward URL by its own field's definition. The stamp the engine writes itself is bounded by nothing. A site owner who registers a consumer with a client id longer than 64 characters gets, on MySQL, a database exception on the first payment that consumer takes — answered as `500 The payment could not be taken.` — and on a server that truncates instead, something worse and quieter: payments are written under a truncated stamp, so `isOwnPayment()` never matches, the consumer is answered `404` for every payment it took, `PaymentNotifier` finds no consumer for the stamp and posts nothing, and two client ids alike for their first 64 characters become one consumer as far as every scoped query is concerned. ### And nothing indexes it `PaymentClientInterface::findPayments()` promises: **"Everything a query names is indexed, so this is a lookup rather than a walk."** `docs/architecture.md` says the same of the schema: "`PaymentStorageSchema` adds the indexes the engine's own queries need." `PaymentStorageSchema::getIndexes()` declares two: `(subject_type, subject_id, account_uuid)` and `(state, expires)`. The consumer column is in neither. It is the one predicate every cross-site read carries. `PaymentApiController::findPayments()` always passes `$this->scope->getConsumerId()`, so every "which payments were taken for this order" from every consuming site narrows on an unindexed column over the whole site's payment history — which on the engine side is every consumer's history, and grows without bound. `PaymentQuery` accepts a consumer as the sole discriminator precisely because that is the multi-tenant question. Both are schema changes, and `docs/architecture.md` already says why they belong before 1.0 rather than after: "An index added later is not applied to an existing site... While kessai is in alpha, reinstalling is the supported way to pick up a schema change." ## What shipped The length is now a constant on the entity, read by the door that refuses one, the way `PaymentMetadata` already holds its two — so the rule a caller is held to and the column it is held to cannot drift apart. And the door refuses: every neighbouring value a caller names is bounded at `create()`, `authorizeToken()` and `chargeToken()`, and this one was not. The index is one column, because the primary key rides along in a secondary index and the id is what the finder orders by, so this reads a consumer's payments newest first without a sort of its own. The contract promised "Everything a query names is indexed", which was not true and is now the three that are, with the rest saying they narrow within what those found. `docs/architecture.md` says the same about the schema. ## Tests | Test | Against the unfixed code | |---|---| | `ConsumerStampTest::testTheColumnHoldsEveryClientIdConsumersAllow` | `Failed asserting that 64 is equal to 255 or is greater than 255` | | `ConsumerStampTest::testThePaymentIsFoundByTheWholeOfTheLongestClientId` | the payment cannot be written at that length | | `PaymentStorageSchemaTest::testTheConsumerIsIndexed` | `The consumer index is created. Failed asserting that false is true` | | `PaymentEngineTest::testEveryCreateDoorRefusesConsumersLongerThanTheColumn` | `create() must refuse a consumer longer than the column records` | The first two are in `kessai_server` deliberately: the length is read off the consumers module's own field, and that is the only module that can see both facts. A test asserting the column against a literal would only say that the test and the field agree with each other — which is what an earlier draft did, and it passed on both SQLite and MySQL with the column back at 64. Both were also run against MySQL, since SQLite does not enforce a varchar length. AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the code and tests on the merge request. I reviewed and ran the work myself before posting it.)