## Problem Two gaps at the engine's own doors, both the same shape: a rule held at one entrance and not at the others. ### What a consumer remembered outlives its payment `hook_kessai_payment_predelete()` deleted a payment's movements, and its docblock gives the reason — a movement carries an amount and a re-linkable provider reference, so a site deleting a payment to honour its retention policy has to see it go. A metadata row carries whatever the consumer chose to remember about the payer's order, in the consumer's own words, and the hook did not touch it. Those were cleared only by `PaymentEngine::deletePayments()`, so a payment deleted through drush, a bulk operation or another module's code left them behind naming a payment id that no longer exists — which is every door but one. The same two lines meant `deletePayments()` deleted the movements itself and then deleted the payments, invoking the hook that deletes them again. ### An amount the column cannot hold `assertAmount()` refused an amount that is not a decimal, and one carrying more precision than money is recorded in, and bounded its magnitude nowhere. The column is `decimal(10,2)`. Every neighboring value is bounded at that door for the reason `assertMetadata()` states: otherwise the figure reaches the database and what the caller gets back is the database's complaint about a column it has never heard of — on the path that takes money, so a payer meets an error page at a checkout. A consumer sending minor units where a decimal was asked for reaches it on its first payment. On SQLite it is worse and quieter: nothing raises and the payment is simply stored out of range. ## What shipped The metadata goes from the hook, beside the movements; `deletePayments()` keeps neither loop. The bound is read off the field's own definition so it cannot drift from the column, and it sits on the guard all four money doors share. One way to ask a column about itself. The bound arrived as a second mechanism — the onward URL asked a payment for its field definition, the new guard asked the field manager — so both go through one helper now. The field manager is the shape that works either side, because one of the two doors refuses an amount before there is any payment to ask, and it is the more honest one: what is being asked about is the column, not the row. The bound is worked out once per request rather than per money operation. It derives from the amount column's own precision and scale, which nothing moves while a request is running, so recomputing it at each door is recomputing a constant. Its sibling, the onward URL's length, still reads straight through: only a derivation is worth holding, and core already caches the definitions behind both. ## Tests | Test | Against the unfixed code | |---|---| | `PaymentDeleteTest::testDeletingPaymentDeletesItsMetadata` | 2 rows survive the delete | | `PaymentDeleteTest::testDeletingPaymentSparesOtherMetadata` | guards a cascade that drops its condition | | `PaymentEngineTest::testAnAmountLargerThanTheColumnIsRefused` | the amount reaches the database | | `PaymentEngineTest::testEveryMoneyDoorHoldsTheAmountBound` | `capture()` stops refusing | Every deletion in `PaymentDeleteTest` goes through storage rather than `deletePayments()`, deliberately: that is the door the rule was missing at. The last one exists because the bound lives on a guard four doors share and only `create()` was covered — moved into `create()` alone it would still have passed the test above while the three that move money took a figure they cannot record. It asserts the clamp beside it: an amount over what is still held is still claimed down to it, which the bound must not quietly replace. On the `test-only changes` lane the amount test reports as an **error** rather than a failure, and the error is the finding: on that lane's MySQL the unfixed engine answers ``` Drupal\Core\Entity\EntityStorageException: SQLSTATE[22003]: Numeric value out of range: 1264 Out of range value for column 'amount' at row 1: INSERT INTO ... kessai_payment ... ``` ## One trade worth seeing `deletePayments()` used to clear the movements for a whole list in one `IN` query. The hook is invoked per payment, so a bulk purge now costs an indexed lookup per payment per row type rather than one per type. Each of the four is indexed — core indexes a movement's reference to its payment, and `PaymentMetadataStorageSchema` indexes its own — the deletion was already per entity inside the one transaction, and the alternative buys a batch for the one door that had the rule and leaves every other door without it. 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.)