From 07201f2b911cf39d0f45162536c54e47e59a804e Mon Sep 17 00:00:00 2001 From: shum Date: Thu, 22 Oct 2026 02:54:16 +0000 Subject: [PATCH] plans: names tasks follow the cancel and overdue rules --- plans/names-codes/2026-10-21-store-service-tasks.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/plans/names-codes/2026-10-21-store-service-tasks.md b/plans/names-codes/2026-10-21-store-service-tasks.md index 0171c6d46c..2a6755620f 100644 --- a/plans/names-codes/2026-10-21-store-service-tasks.md +++ b/plans/names-codes/2026-10-21-store-service-tasks.md @@ -202,10 +202,10 @@ This is the implementation plan for the names backend in StoreService: stages 2, - **Do:** the contract's section 5 for `/api/invoice` and cancel, in its order of checks; publish after every commit. - Orders run under `withLabelTurn` (T4's `Turns`). - **`live`:** every transition that changes it is in this task, in the same transaction as the change: settlement (past `unpaid`, live), cancel (`cancelOpenInvoice`), the poller's overdue sweep (`expireOverdue`) and its expiry of an invoice it reads, a late payment of a closed invoice (stays not live), the 30-day cleanup (deleted), and phase changes to `taken` or `code_issued` (not live). - - **An overdue order is closed by the next one:** a new order from the same wallet and name that meets a live order whose invoice is past its expiry time calls `closeOverdue` in its own transaction, then inserts; after the commit it asks the provider to cancel the old invoice, best effort. + - **An overdue order is closed by the next one:** a new order from the same wallet and name that meets a live order whose invoice is past its expiry time with no money received calls `closeOverdue` in its own transaction, then inserts; after the commit it asks the provider to cancel the old invoice, best effort. - **Settlement queues only a live registration.** A settled signal for a closed one (cancelled, expired, or closed by a newer order) is a late payment: the invoice is marked paid, the registration stays `unpaid`, the operator is alerted, support refunds it. - **Acceptance:** badge invoices unchanged (their tests green); a name invoice's view, and the registration view inside it, as the contract's. -- **Tests** (the plan's Verification, orders): a paid order; an exact resend answered with the same invoice, even after the timestamp window, with a new timestamp and signature, and after the registration went past `unpaid` (answered before the chain read); an exact resend of an expired order answered with its expired invoice; a new order of the same wallet and name accepted after a cancel, and after the old invoice's expiry time before the poller marks it (closing the old one); a payment of the old invoice arriving after a newer order replaced it, recorded as a late payment with an alert and the new order unaffected; a stale timestamp on a new order refused; a resend differing in any one field (including `sealed`) refused `409 order_exists` with no other field; an order for the same owner and hash with a new commitment refused the same way; an order carrying someone else's public commitment refused without disclosing anything; a bad or other signer's signature refused; two concurrent orders for one owner and hash, one winning; the duration slack before and after `termStart`; `catalog_changed` with the chain price; `name_taken` for registered, reserved and being registered here; `name_check_unavailable`; `sealed` missing or over 11095 and a body over 16384 refused, a longest order accepted; two orders for one name from two wallets both accepted (the later one ends `taken` in T17); cancel answers (`funded`, `not_open`, `200 paid`, `200 expired` with marks, still `open`); a late payment of a closed invoice leaving `unpaid` and alerting; the cleanup deleting an `unpaid` registration after 30 days, sparing one that received a payment, recording a payment found only at cleanup, keeping it when the provider does not answer; the view's `unread` on a failed `intentNonce` read, and on a failed `codeLength` read in `taken`. +- **Tests** (the plan's Verification, orders): a paid order; an exact resend answered with the same invoice, even after the timestamp window, with a new timestamp and signature, and after the registration went past `unpaid` (answered before the chain read); an exact resend of an expired order answered with its expired invoice; a new order of the same wallet and name accepted after a cancel, and after the old invoice's expiry time before the poller marks it (closing the old one); a payment of the old invoice arriving after a newer order replaced it, recorded as a late payment with an alert and the new order unaffected; a stale timestamp on a new order refused; a resend differing in any one field (including `sealed`) refused `409 order_exists` with no other field; an order for the same owner and hash with a new commitment refused the same way; an order carrying someone else's public commitment refused without disclosing anything; a bad or other signer's signature refused; two concurrent orders for one owner and hash, one winning; the duration slack before and after `termStart`; `catalog_changed` with the chain price; `name_taken` for registered, reserved and being registered here; `name_check_unavailable`; `sealed` missing or over 11095 and a body over 16384 refused, a longest order accepted; two orders for one name from two wallets both accepted (the later one ends `taken` in T17); cancel answers (`funded`, `not_open`, `200 paid`, `200 expired` with marks); a late payment of a closed invoice leaving `unpaid` and alerting; the cleanup deleting an `unpaid` registration after 30 days, sparing one that received a payment, recording a payment found only at cleanup, keeping it when the provider does not answer; the view's `unread` on a failed `intentNonce` read, and on a failed `codeLength` read in `taken`. - **Depends on:** T3, T6, T8. #### T12. Orders paid with a prepaid code