>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3615441. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !188 >>> <p>Nothing deletes a <code>yoyaku_transaction</code> in any state, so orders accumulate for the life of the site. The only cron sweeps are hold expiry, settlement, checkout reclaim and manager grants.</p> <p><span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/yoyaku/-/work_items/3615440" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/yoyaku/-/work_items/3615440</a></span> shipped the configuration for this and nothing else: <code>order_retention</code>, a state-keyed mapping on <code>yoyaku.settings</code> and <code>yoyaku.tenant.*</code> resolving tenant then site, deliberately not channel, because how long a booker's session lasts is a front's business while how long data is kept is the realm's. Nothing reads it yet. It also made empty orders routine, by ending a lapsed basket as <code>empty</code> rather than cancelling it, which is the right end state but leaves a contentless row behind every time.</p> <p>The sweep is one cron query per configured state, <code>state = X AND changed &amp;lt;= now - retention</code>, ordered by <code>changed</code>, batch-limited and queued, the same bucketing <code>sweptResourcesByGrace()</code> already does for settlement. The <code>[&amp;#039;state&amp;#039;, &amp;#039;changed&amp;#039;]</code> composite it needs is already on <code>BookingTransactionStorageSchema</code>. An absent key means never delete, the reading a policy's <code>enabled</code> already carries, and the active states (pending, locked, placed, confirmed) are never eligible whatever is configured.</p> <p>The part that needs designing is the guards, and it is why the sweep was left out of <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/yoyaku/-/work_items/3615440" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/yoyaku/-/work_items/3615440</a></span> rather than shipped half-formed. An order must not be deleted while something still points at it, and only one of the three things that might is visible to the core module: whether it still has a line. The other two are a running Orchestra instance referencing it, which only <code>yoyaku_orchestra</code> can answer, and a payment row against it, which only <code>yoyaku_payment</code> can. Core cannot ask either without depending on it, so this needs a seam: a tagged <code>OrderDeletionGuardInterface</code> with any veto stopping the deletion, or an event the submodules may veto. The tagged service is the more predictable of the two and matches how availability bounds are already collected.</p> <p>Two buckets are easy and go first. An <code>empty</code> order is definitionally contentless, and a <code>cancelled</code> one is the record of a booking that did not happen, so the accounting stakes are low; the payment guard is what does the real work there, since a cancellation that involved a refund is a record and must be left alone. P7D and P30D are the proposed defaults.</p> <p>The settled states are the hard half, and the reason this is a plan rather than a task. Deleting a completed order destroys the record that a booking happened, and cascades into its lines, its payments, its tickets and any fee retained against it, all of which have accounting lives of their own. The reason to want a policy there is usually personal data rather than volume: the booker's name and address sit on the order. That argues for anonymizing a settled order rather than deleting it, keeping the booking and dropping the person. Which of the two, and whether the choice is made per state, is the decision this issue exists to make.</p> <p>Remaining tasks: pick and build the guard seam, with a guard in each of <code>yoyaku_orchestra</code> and <code>yoyaku_payment</code>; the cron query and its queue worker; the <code>order_retention</code> fields on the tenant and site settings forms, which the configuration shipped without; decide delete against anonymize for the settled states and build whichever wins; tests, the one that matters most being that a guarded order survives a sweep it is otherwise eligible for; and the documentation. The deletion cascade itself is already covered by <code>TransactionDeleteCascadeTest</code>.</p>