## Problem `PaymentEngine::assertMetadata()` refuses an empty value, as it already refuses an empty name, and says which end of the bound it is. The guard's own docblock already named this failure — *"the payment would be found by a value nobody asked about, **or by nothing at all**"* — and guarded only the first of the two. It held the top of the range and not the bottom. A value of `''` passed, and then: Drupal writes no value for an empty field item, so the column took `NULL`; `readMetadata()` cast the `NULL` back to `''`, so the payment read as carrying the name it was asked to carry; and `paymentIdsCarrying()` compared `''` against a `NULL` and matched nothing. Accepted, reads back correct, findable by nothing — which is the whole of what a consumer keeps metadata for. Observed against unpatched `1.x`: ``` create(metadata: ['empty' => '', 'filled' => 'yes']) rows: {name: "empty", value: null} {name: "filled", value: "yes"} getMetadata() => {"empty":"", "filled":"yes"} findPayments(metadata: ['empty' => '']) => 0 payments findPayments(metadata: ['filled' => 'yes']) => 1 payment ``` `value` is `setRequired(TRUE)`, but `SqlContentEntityStorageSchema` marks only entity keys `not null` in a shared table, so no database refuses it either. ## The same sentence, three more times, on the way in from another host A caller on this site meets the engine's refusals. A consumer on another host reaches the same doors through `PaymentApiController`, and what it sent was read by casting and dropping rather than by refusing — so the engine's rules held on one side of the wire only. **A value the reader could not carry was left out.** `readStringMap()` kept what `is_scalar()` and discarded the rest, so `{"order_ref": null}` — the value a computation produces at least as readily as `''` — was answered **201** with the name simply absent. Worse than the case above, because the payment does not even read back as carrying it, and metadata is written once, so the consumer has no later moment to put it right. **A condition dropped from a query widens the answer.** The same drop on `readStringList()` meant a state that came out `null` was left out, and the consumer that asked for the payments in one state was handed the payments in **every** state, with nothing in the answer to say the question had changed. **A body that could not be read became an empty question.** Taking a payment already refused one and said so; reading and settling read it as `[]`. An empty question to the finder is every payment the consumer holds, and an empty body to a capture is the **whole of the hold**: `capture()` takes no amount to mean whatever is still held, and closes the payment by default, so what it did not claim could never be claimed afterwards. **A field that could not be read was cast into one that could.** A subject id that was not a word became the word `Array`, which belongs to no subject and which every such payment would share; a deadline that was not a number became the moment zero; and `store_token` read through `(bool)` made the string `"false"` a **true** value — the payer's card kept on file by a request that asked that it not be. ## Proposed - The engine refuses an empty metadata value, at all three creation doors. - The wire's readers refuse what they cannot read instead of dropping or casting it, and each refusal names the field and says what arrived. All three callers already answer `\InvalidArgumentException` as the refusal it is: 422 on the two write doors, 400 on the query. - The ids door keeps the opposite rule, which it already documents — what a consumer does not hold is left out rather than refused, because refusing says the id is real — so it reads its own list rather than sharing one with a door that refuses. **Null is not one of those.** This protocol writes an optional field it was given nothing for as an explicit null: the client sends `"deadline": null` and `"subject_id": null` on ordinary calls. So null is how it says nothing, and it goes on meaning that. An earlier turn of this work had these doors refusing it, which refused every payment the module's own client takes; the suite said so. ## Tests - `PaymentEngineTest::testEveryCreateDoorHoldsTheMetadataBound` gains an empty value to its refused shapes, so all three creation doors are held to it and none of the twelve refusals leaves a payment behind. - `AcrossTheWireTest` gains the cases for a consumer on another host, beside the one already there for a value that is too long. Those that are about what a request may carry are asked as a body rather than through the client, because the client types what it sends and the request that has to be refused is the one that does not keep to those types. - Each refusal is asserted as the status a consumer actually receives. Against the unpatched code they read `201 is identical to 422` and `200 is identical to 400`: the payment was taken, the query was answered. ## Prose `PaymentRequest` and the three `@throws` on `PaymentClientInterface`'s creation doors state the bound at both ends, and say what the empty case costs: a payment found by nothing rather than by the wrong thing. AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the change and its tests. Each behavioural fix has a test that was run against the unpatched code and seen to fail, and seen to pass with the change.)