@blamejs/blamejs-shop 0.4.61 → 0.4.63

package/CHANGELOG.md

@@ -8,6 +8,10 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- v0.4.63 (2026-06-19) — **Fulfillment and customer-data actions can't double-fire under concurrent calls.** Closes a further set of concurrency races where a fulfillment or customer-data action read a row, checked its status in application code, and then performed an irreversible side-effect (open an inventory hold, create shipments, restock received stock, create an order, reparent customer records, requeue a print job, mint child carts) before an unconditional update committed — so two concurrent calls could both pass the check and both perform the side-effect. Each now claims the transition with a single conditional update and performs the side-effect only when that claim wins, reverting the claim if the side-effect then fails so a row is never stranded. Approving an exchange opens its replacement hold once; executing a split-shipment plan creates the parcels once; recording a partial purchase-order receipt restocks each line once (claimed per line); completing a pick list creates its shipment once; converting or launching a pre-order creates the order once and a reservation can't oversell its cap; merging or rolling back a customer reparents the records once; an impersonation notice, a duplicate-suggestion link, a print-job retry, and a cart split each happen once. Behavior for a single sequential caller is unchanged. **Fixed:** *Fulfillment transitions claim before their side-effect* — Approving an exchange now claims pending-to-approved (WHERE id = ? AND status = 'pending') before opening the replacement inventory hold, reverting to pending if the hold fails. Executing a split-shipment plan claims proposed-to-executed before creating any shipment. Recording a partial purchase-order receipt claims each receipt line by advancing its received quantity conditionally before restocking, rolling the claimed lines back if a later line fails. Completing a pick list claims its completion before creating the shipment. In each case two concurrent calls can no longer both create the holds / shipments / restock for one row. · *Pre-order conversion, launch, cancel, and reserve are atomic* — Converting a reservation to an order claims active-to-converted before creating the order (reverting on failure), so a reservation can't spawn two orders; launching a campaign claims active-to-launched before walking reservations; cancelling claims active-to-cancelled before decrementing the reserved counter. Reserving now enforces the campaign cap inside the increment itself (units_reserved + qty <= max_units_available in the update's WHERE), so concurrent reservations can't oversell the pool; a reservation that loses the cap is compensated. · *Customer merge/rollback, impersonation notice, suggestion dedup, print retry, and cart split run once* — Executing or rolling back a customer merge claims the transition before reparenting records, reverting if the reparent fails. Sending the 'an operator viewed your account' notice claims the notified stamp (WHERE customer_notified_at IS NULL) before enqueuing, so it's sent once. Linking a duplicate suggestion claims the source before migrating its votes to the canonical row. Marking a print job failed claims the transition before inserting the retry job, so a job isn't reprinted twice. Splitting a cart claims the source's abandon before minting the child carts, so a concurrent split can't create two sets of children.
+
+- v0.4.62 (2026-06-19) — **Money and approval actions can't double-fire under concurrent calls.** Closes a set of concurrency races in money- and approval-critical paths where the action read a row, checked its status in application code, and then performed an irreversible side-effect (retry a card, execute an approved action, register a vendor, bill a subscription change) before an unconditional update committed — so two concurrent calls could both pass the check and both perform the side-effect. Each now claims the transition with a single conditional update and performs the side-effect only when that claim wins. A scheduled payment retry is claimed out of the due set before the processor is called, so an overlapping scheduler tick can't retry the same card twice; a payment outcome is claimed by its attempt number before the attempt is recorded, so a redelivered webhook can't double-count it. Executing an approved operator request claims the approved-to-executed transition before returning success, so the underlying money move runs once. Approving a seller application claims the in-review-to-approved transition before registering the vendor (rolling back to in-review if registration fails), so one application can't create two vendors. Applying scheduled subscription plan changes claims each pending change before updating the plan and recording its proration invoice, and stamps a deterministic idempotency key on the invoice, so an overlapping or retried scheduler run can't bill the proration twice. Behavior for a single sequential caller is unchanged. **Fixed:** *Scheduled payment retries and recorded outcomes claim before acting* — The retry scheduler now claims each due enrollment (nulling its next-retry time, conditional on the value the tick observed) before composing the processor retry, so two overlapping ticks can't both retry the same card for one scheduled slot — only the claim winner calls the processor. Recording a retry outcome claims the enrollment by bumping its attempt count conditionally on the observed value before writing the attempt row, so a redelivered webhook (or a manual record racing it) can't write a duplicate attempt or double-count toward the cap; the loser returns the already-advanced row. · *Executing an approved request runs the action once* — markExecuted now flips the request from approved to executed with a conditional update (WHERE id = ? AND status = 'approved') and returns success only when that update changes one row; a concurrent second call is refused with a typed error before the application runs the underlying action (a large refund, vendor payout, or bulk operation) a second time. · *Approving a seller application creates one vendor* — approveApplication now claims the in-review-to-approved transition first and registers the vendor only when the claim wins, so two concurrent approvals can't both register a vendor for one application. If vendor registration fails after the claim, the application is rolled back to in-review so it can be approved again rather than stranded as approved with no vendor. · *Applying scheduled plan changes bills the proration once* — applyScheduledChanges now claims each pending change (WHERE id = ? AND status = 'pending') before updating the subscription plan and recording the proration invoice, so an overlapping or retried scheduler run skips an already-applied change instead of billing it twice. Both the scheduled and the immediate plan-change paths now stamp a deterministic idempotency key on the proration invoice, so even a re-run that reached the billing call would dedupe against the unique invoice id rather than write a second charge. A regression test asserts a second apply pass records no additional invoice.
+
 - v0.4.61 (2026-06-19) — **Scheduled and dispatched sends no longer double-fire under concurrent ticks.** Closes a class of concurrency races in the scheduled-send and dispatch paths where a tick read a row, checked its status or schedule cursor in application code, and then performed the send (and its ledger write) before an unconditional update committed — so two overlapping ticks (a cron overrun, two workers, or a manual tick racing the schedule) could both pass the check and both send. Each path now claims the row with a single conditional update — flipping the status, or advancing the schedule cursor, only when the row is still in the expected state — and performs the send only when that claim wins; the losing tick changes zero rows and skips. The affected sends: an email campaign drain (the whole audience could be mailed twice), a queued push notification, a wishlist digest email and its sent-ledger row, a reorder reminder, a survey response record, and a dunning step's reminder email / subscription action. Behavior for a single (sequential) caller is unchanged; only the concurrent double-fire is removed. Where a send fails after the claim wins, the schedule cursor is rolled back so the row is retried on the next tick rather than skipped. **Fixed:** *Email campaign sends claim the campaign before draining* — sendNow, the scheduled dispatch tick, and the consent-gated broadcast drain now flip the campaign from scheduled to sending with a conditional update (WHERE slug = ? AND status = 'scheduled') and drain only when that update changes exactly one row. Previously the status check ran in application code before an unconditional flip, so two concurrent sends could both drain and mail the entire audience twice. The losing caller refuses (a typed send-race error) or, for the tick, skips the campaign. · *Push, wishlist-digest, and reorder-reminder ticks claim each row before sending* — Each per-row advance is now the atomic claim: a queued push notification advances to sent/failed only via WHERE id = ? AND status = 'queued'; a wishlist digest and a reorder reminder advance their schedule cursor with WHERE id = ? AND next_*_at = <the observed value>. The external send (and, for the digest, its sent-ledger row) runs only when the claim changes one row, so two overlapping ticks can't both dispatch the same row. A send that fails after winning the reminder claim rolls the cursor back so the row retries next tick. · *Survey responses and dunning steps gate their side-effect on an atomic claim* — Submitting a survey response now flips the invitation from issued to responded with WHERE id = ? AND status = 'issued' and inserts the response row only when that claim wins (a lost race returns a typed already-responded error), so a double-submit can't record two responses for one invitation. A dunning tick now claims the enrollment with WHERE id = ? AND status = 'active' AND next_action_at = <the observed value> before executing the step (the reminder email / in-app notification / pause or cancel), so overlapping dunning ticks can't send a step twice; the subsequent state transitions carry the same status guard.
 
 - v0.4.60 (2026-06-19) — **Free-shipping discount rules now actually waive the shipping charge.** Fixes a checkout defect that made a free_shipping auto-discount rule a complete no-op on the amount charged: the discount engine correctly flagged the order as free-shipping-eligible, but checkout dropped that flag and still billed the customer the full selected shipping rate. A matched free_shipping rule now zeroes the charged shipping in the quote and the confirmed order (the selected rate is still shown so the customer sees what was waived), so the payment is for merchandise and tax only. The rule is also now reserved against its redemption like every other auto-discount, so a free_shipping rule with a usage cap is enforced instead of applying without limit. Subtotal discounts are unaffected — free shipping reduces the shipping line, not the subtotal, and tax (computed on the post-discount subtotal) is unchanged. **Fixed:** *free_shipping auto-discount waives the charged shipping* — A matching free_shipping rule was flagged by the auto-discount engine but never applied to the amount charged — checkout excluded it from the discount (correct, since free shipping is not a subtotal reduction) but then charged the full shipping rate, so the rule saved the customer nothing. The quote and the confirmed order now set the charged shipping to zero when a free_shipping rule matches; the selected shipping service and its rate are still surfaced so the storefront can show the waived amount. The free_shipping rule is included in the order's applied auto-discounts and reserved against its redemption pre-charge, so a capped free-shipping rule is enforced and recorded the same way a percentage or amount-off rule is. A checkout integration test now asserts the charged total, the confirmed order total, and the payment amount all exclude shipping when free shipping applies.

package/lib/asset-manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.4.61",
+  "version": "0.4.63",
   "assets": {
     "css/admin.css": {
       "integrity": "sha384-imfe0otYErcB8rr2h6KLSGTtStirysptpXETSPY4zLv3bZoIT75Lo1dOvkOav+xL",

package/lib/cart-bulk-ops.js

@@ -516,12 +516,23 @@ function create(opts) {
       // carts are not the shopper's working cart, they're scratch
       // carts for downstream fulfillment / split-order quoting).
       var ts = _now();
-      // Mark source abandoned first so the active-session index is
-      // free for any reuse.
-      await query(
-        "UPDATE carts SET status = 'abandoned', updated_at = ?1 WHERE id = ?2",
+      // Atomic claim: mark the source abandoned in a single
+      // conditional UPDATE that re-checks `status = 'active'` in its
+      // own WHERE. `_loadCart` read the status in JS, but two
+      // concurrent splitCart calls would both pass that check and
+      // both mint a full set of child carts (double-create). SQLite /
+      // D1 serializes writers, so exactly one of the racing UPDATEs
+      // flips active→abandoned (rowCount === 1) and earns the right
+      // to mint the children; the loser sees rowCount === 0 and
+      // refuses rather than producing a second set of child carts.
+      // This also frees the active-session index for any reuse.
+      var claim = await query(
+        "UPDATE carts SET status = 'abandoned', updated_at = ?1 WHERE id = ?2 AND status = 'active'",
         [ts, input.cart_id],
       );
+      if (Number(claim.rowCount || 0) !== 1) {
+        throw new TypeError("cartBulkOps.splitCart: cart " + input.cart_id + " already split/modified");
+      }
       var children = [];
       for (var gi = 0; gi < groupOrder.length; gi += 1) {
         var groupKey = groupOrder[gi];

package/lib/customer-impersonation.js

@@ -492,6 +492,20 @@ function create(opts) {
       if (!notifications) {
         return { notified: false, customer_notified_at: null };
       }
+
+      // Enqueue FIRST, then record the confirmation stamp — so
+      // `customer_notified_at` only ever means "the notice was
+      // successfully enqueued", never "claimed but the enqueue may have
+      // failed". A claim-before-enqueue stamp let a concurrent caller
+      // observe the provisional stamp and report `notified: true` while
+      // the winner's enqueue was still pending (and might then throw and
+      // roll the stamp back), silently dropping the privacy notice.
+      // Recording the stamp only on enqueue success closes that. A
+      // concurrent caller that also slipped past the null-check above may
+      // enqueue a second time; a duplicate "an operator viewed your
+      // account" notice is benign and strictly preferable to missing it,
+      // and the audit stamp still resolves to a single value.
+      var now = _now();
       await notifications.enqueue({
         recipient_id: existing.customer_id,
         channel:      "account-impersonation",
@@ -506,12 +520,21 @@ function create(opts) {
           expires_at:       Number(existing.expires_at),
         },
       });
-      var now = _now();
+
+      // Stamp the confirmation idempotently — the first writer to land
+      // wins (WHERE customer_notified_at IS NULL); a concurrent second
+      // caller's UPDATE matches zero rows and returns the already-
+      // recorded stamp. An enqueue throw above propagates before this,
+      // leaving the row un-stamped so a retry re-attempts delivery.
       await query(
-        "UPDATE impersonations SET customer_notified_at = ?1 WHERE id = ?2",
+        "UPDATE impersonations SET customer_notified_at = ?1 " +
+        "WHERE id = ?2 AND customer_notified_at IS NULL",
         [now, id],
       );
-      return { notified: true, customer_notified_at: now };
+      var stampedRow = await _getRow(id);
+      var stampedAt  = stampedRow && stampedRow.customer_notified_at != null
+        ? Number(stampedRow.customer_notified_at) : now;
+      return { notified: true, customer_notified_at: stampedAt };
     },
 
     // ---- listForOperator ------------------------------------------------

package/lib/customer-merge.js

@@ -693,26 +693,70 @@ function create(opts) {
         throw drErr;
       }
 
-      // Commit every reparent.
-      var actual = await _reparentAll(row.source_customer_id, row.target_customer_id);
-
-      // Archive the source customer + insert the redirect marker.
-      await customers.archiveCustomer(row.source_customer_id);
+      // Atomically CLAIM the proposed->executed transition BEFORE
+      // running any exactly-once side effect. SQLite serializes
+      // writers, so this conditional UPDATE is the race-free claim:
+      // two concurrent executeMerge calls on the same proposed row
+      // both pass the JS status check above, but only one lands
+      // rowCount===1 here — the loser sees rowCount 0 and bails out
+      // returning the now-executed row, so the reparent / archive /
+      // redirect-insert fire exactly once.
       var ts = _now();
-      await query(
-        "INSERT INTO customer_merge_redirects " +
-        "(source_customer_id, target_customer_id, merge_id, executed_at) " +
-        "VALUES (?1, ?2, ?3, ?4)",
-        [row.source_customer_id, row.target_customer_id, mergeId, ts],
+      var claim = await query(
+        "UPDATE customer_merges SET status = 'executed', " +
+        "executed_at = ?1, executed_by = ?2 WHERE id = ?3 AND status = 'proposed'",
+        [ts, executedBy, mergeId],
       );
+      if (Number(claim.rowCount || 0) !== 1) {
+        // Lost the race (or the row left 'proposed' between our read
+        // and the claim). Re-read: an already-executed row is the
+        // winner's result; anything else is a genuine state error.
+        var current = await _getMergeRow(mergeId);
+        if (current && current.status === "executed") {
+          return _hydrateMerge(current);
+        }
+        var raceErr = new Error("customerMerge.executeMerge: merge_id " + mergeId +
+          " is no longer proposed, only proposed merges can be executed");
+        raceErr.code = "CUSTOMER_MERGE_NOT_PROPOSED";
+        throw raceErr;
+      }
 
-      // Land the merge in executed; freeze the actual reparent
-      // counts on plan_json so rollback has the exact footprint.
+      // Claim won — now run the exactly-once side effects. If any
+      // throws, REVERT the claim (self-targeting the row we just
+      // flipped) so the merge isn't stranded in 'executed' with the
+      // reparents only partially applied; then rethrow.
+      var actual;
+      try {
+        // Commit every reparent.
+        actual = await _reparentAll(row.source_customer_id, row.target_customer_id);
+
+        // Archive the source customer + insert the redirect marker.
+        await customers.archiveCustomer(row.source_customer_id);
+        await query(
+          "INSERT INTO customer_merge_redirects " +
+          "(source_customer_id, target_customer_id, merge_id, executed_at) " +
+          "VALUES (?1, ?2, ?3, ?4)",
+          [row.source_customer_id, row.target_customer_id, mergeId, ts],
+        );
+      } catch (sideErr) {
+        await query(
+          "UPDATE customer_merges SET status = 'proposed', " +
+          "executed_at = NULL, executed_by = NULL WHERE id = ?1 AND status = 'executed'",
+          [mergeId],
+        );
+        throw sideErr;
+      }
+
+      // Freeze the actual reparent counts on plan_json so rollback
+      // has the exact footprint. Status / executed_at / executed_by
+      // already landed in the claim above.
       var sealed = Object.assign({}, capturedPlan, { actual: actual });
+      // Gate on still-'executed' so this metadata seal can't land on a
+      // row a concurrent rollback (now allowed once the redirect exists)
+      // has already flipped to 'rolled_back'.
       await query(
-        "UPDATE customer_merges SET status = 'executed', plan_json = ?1, " +
-        "executed_at = ?2, executed_by = ?3 WHERE id = ?4",
-        [JSON.stringify(sealed), ts, executedBy, mergeId],
+        "UPDATE customer_merges SET plan_json = ?1 WHERE id = ?2 AND status = 'executed'",
+        [JSON.stringify(sealed), mergeId],
       );
       return _hydrateMerge(await _getMergeRow(mergeId));
     },
@@ -743,6 +787,8 @@ function create(opts) {
         throw stErr;
       }
       var now = _now();
+      // Keep the in-window check BEFORE the claim — a past-window
+      // merge must refuse without flipping status.
       if (now - Number(row.executed_at) > ROLLBACK_WINDOW_MS) {
         var winErr = new Error("customerMerge.rollbackMerge: merge_id " + mergeId +
           " executed " + Math.floor((now - Number(row.executed_at)) / C.TIME.days(1)) +
@@ -752,21 +798,56 @@ function create(opts) {
         throw winErr;
       }
 
-      // Reverse every reparent (target -> source).
-      await _reparentAll(row.target_customer_id, row.source_customer_id);
-
-      // Restore the source customer + drop the redirect marker.
-      await customers.restoreCustomer(row.source_customer_id);
-      await query(
-        "DELETE FROM customer_merge_redirects WHERE source_customer_id = ?1",
-        [row.source_customer_id],
-      );
-
-      await query(
+      // Atomically CLAIM the executed->rolled_back transition BEFORE
+      // running the reverse reparent / restore / redirect-delete.
+      // The conditional UPDATE is the race-free guard: two concurrent
+      // rollbackMerge calls both pass the JS status + window checks,
+      // but only one lands rowCount===1 here — the loser bails out so
+      // the reverse side effects fire exactly once.
+      // Gate the claim on the redirect row EXISTING. executeMerge flips
+      // status to 'executed' BEFORE its reparent/archive complete and
+      // inserts the redirect as its LAST side effect, so the redirect's
+      // presence is the proof that the reparent + archive are durable.
+      // Without this gate a rollback racing an in-flight execute (status
+      // already 'executed', reparents not yet done) would flip to
+      // 'rolled_back' and reverse nothing. If the redirect isn't there
+      // yet the merge is still finalizing — refuse so the caller retries.
+      var claim = await query(
         "UPDATE customer_merges SET status = 'rolled_back', " +
-        "rolled_back_at = ?1, rollback_reason = ?2 WHERE id = ?3",
-        [now, reason, mergeId],
+        "rolled_back_at = ?1, rollback_reason = ?2 WHERE id = ?3 AND status = 'executed' " +
+        "AND EXISTS (SELECT 1 FROM customer_merge_redirects WHERE source_customer_id = ?4)",
+        [now, reason, mergeId, row.source_customer_id],
       );
+      if (Number(claim.rowCount || 0) !== 1) {
+        var raceErr = new Error("customerMerge.rollbackMerge: merge_id " + mergeId +
+          " is no longer executed (or its merge is still finalizing); only fully-executed merges can be rolled back");
+        raceErr.code = "CUSTOMER_MERGE_NOT_EXECUTED";
+        throw raceErr;
+      }
+
+      // Claim won — now run the reverse side effects. If any throws,
+      // REVERT the claim (self-targeting the row we just flipped) so
+      // the merge isn't stranded in 'rolled_back' with the reparents
+      // only partially reversed; then rethrow.
+      try {
+        // Reverse every reparent (target -> source).
+        await _reparentAll(row.target_customer_id, row.source_customer_id);
+
+        // Restore the source customer + drop the redirect marker.
+        await customers.restoreCustomer(row.source_customer_id);
+        await query(
+          "DELETE FROM customer_merge_redirects WHERE source_customer_id = ?1",
+          [row.source_customer_id],
+        );
+      } catch (sideErr) {
+        await query(
+          "UPDATE customer_merges SET status = 'executed', " +
+          "rolled_back_at = NULL, rollback_reason = NULL WHERE id = ?1 AND status = 'rolled_back'",
+          [mergeId],
+        );
+        throw sideErr;
+      }
+
       return _hydrateMerge(await _getMergeRow(mergeId));
     },
 

package/lib/operator-approvals.js

@@ -724,11 +724,25 @@ function create(opts) {
     }
 
     var ts = _monotonicTs();
-    await query(
+    // Atomic claim: gate the approved->executed transition on the row
+    // still being 'approved'. The JS check above only refuses a
+    // sequential re-execute; two concurrent markExecuted calls would
+    // both read 'approved', both pass that check, and both return
+    // success — so the application would run the underlying money move
+    // (a large refund / vendor payout / bulk catalog action) TWICE. The
+    // `AND status = 'approved'` predicate lets exactly one caller win
+    // the transition; the loser is refused before its side-effect runs.
+    var claim = await query(
       "UPDATE approval_requests SET status = 'executed', executed_by = ?1, " +
-      "executed_at = ?2, result_json = ?3, updated_at = ?2 WHERE id = ?4",
+      "executed_at = ?2, result_json = ?3, updated_at = ?2 WHERE id = ?4 AND status = 'approved'",
       [executedBy, ts, resultJson, requestId],
     );
+    if (Number(claim.rowCount || 0) !== 1) {
+      var raced = new Error("operatorApprovals.markExecuted: request " +
+        JSON.stringify(requestId) + " is no longer approved — execution refused");
+      raced.code = "APPROVAL_EXECUTE_RACE";
+      throw raced;
+    }
 
     await _audit("approval.execute", executedBy, requestId,
       { status: req.status },

package/lib/order-exchanges.js

@@ -286,28 +286,59 @@ function create(opts) {
       }
       _assertTransition(existing.status, "approveExchange");
 
-      // Pin the replacement shelf BEFORE flipping the DB row. A
-      // hold failure (insufficient stock, unknown location)
-      // surfaces to the caller; the row stays pending so the next
-      // operator attempt decides whether to retry, source from a
-      // different shelf, or reject the exchange.
-      if (invAllocs) {
-        await invAllocs.holdForCart({
-          cart_id:    existing.id,
-          sku:        existing.replacement_sku,
-          variant_id: existing.replacement_variant_id || null,
-          quantity:   existing.replacement_qty,
-          // allow:raw-time-literal — hold TTL in SECONDS (passed to holdForCart's ttl_seconds); C.TIME returns ms
-          ttl_seconds: input.hold_ttl_seconds || 86400,
-        });
-      }
-
+      // Claim pending -> approved ATOMICALLY before the inventory
+      // hold. The conditional WHERE (status = 'pending') is the
+      // serialization point: two operators racing the same exchange
+      // both pass the JS _assertTransition above, but only the writer
+      // whose UPDATE matches a still-pending row wins (rowCount === 1).
+      // The loser's UPDATE matches zero rows -> it refuses here and
+      // never opens a duplicate hold. Without this, both callers would
+      // reach holdForCart and pin the replacement SKU twice.
       var ts = _monotonicTs();
-      await query(
+      var claim = await query(
         "UPDATE order_exchanges SET status = 'approved', approver_id = ?1, updated_at = ?2 " +
-        "WHERE id = ?3",
+        "WHERE id = ?3 AND status = 'pending'",
         [approverId, ts, exchangeId],
       );
+      if (Number(claim.rowCount || 0) !== 1) {
+        var refused = new Error(
+          "order-exchanges: transition 'approveExchange' refused from state '" +
+          existing.status + "' (lost the race to a concurrent transition)"
+        );
+        refused.code = "EXCHANGE_TRANSITION_REFUSED";
+        throw refused;
+      }
+
+      // Pin the replacement shelf AFTER winning the claim. A hold
+      // failure (insufficient stock, unknown location) surfaces to the
+      // caller; we revert the claim back to pending so the next
+      // operator attempt decides whether to retry, source from a
+      // different shelf, or reject the exchange — the row is never
+      // stranded in `approved` without a hold.
+      if (invAllocs) {
+        try {
+          await invAllocs.holdForCart({
+            cart_id:    existing.id,
+            sku:        existing.replacement_sku,
+            variant_id: existing.replacement_variant_id || null,
+            quantity:   existing.replacement_qty,
+            // allow:raw-time-literal — hold TTL in SECONDS (passed to holdForCart's ttl_seconds); C.TIME returns ms
+            ttl_seconds: input.hold_ttl_seconds || 86400,
+          });
+        } catch (holdErr) {
+          // Self-targeting revert: only un-claim the row WE just
+          // claimed (status still 'approved'). A concurrent follow-on
+          // transition that already moved the row off `approved` is
+          // left untouched.
+          await query(
+            "UPDATE order_exchanges SET status = 'pending', approver_id = NULL, updated_at = ?1 " +
+            "WHERE id = ?2 AND status = 'approved'",
+            [_monotonicTs(), exchangeId],
+          );
+          throw holdErr;
+        }
+      }
+
       return await _getRow(exchangeId);
     },
 

package/lib/payment-retries.js

@@ -587,6 +587,23 @@ function create(opts) {
       var advanced = [];
       for (var i = 0; i < due.rows.length; i += 1) {
         var enrollment = due.rows[i];
+        // Atomic claim: take this enrollment out of the due set (null its
+        // next_retry_at) gated on the value THIS tick observed, BEFORE any
+        // processor work. Two overlapping ticks (cron overrun / two
+        // workers / a manual tick racing the cron) both snapshot the same
+        // active+due row; only the one whose conditional UPDATE matches
+        // one row proceeds to _tickAdvance, which composes
+        // paymentHandle.retryIntent (the real card-charge retry). The
+        // loser changes zero rows and skips, so the customer's card is
+        // retried exactly once per scheduled slot. _tickAdvance re-stamps
+        // next_retry_at to the true next slot (or a terminal NULL).
+        var claim = await query(
+          "UPDATE payment_retry_enrollments SET next_retry_at = NULL " +
+          "WHERE id = ?1 AND status = 'active' AND next_retry_at = ?2",
+          [enrollment.id, enrollment.next_retry_at],
+        );
+        if (Number(claim.rowCount || 0) !== 1) continue;   // another tick claimed it
+
         var policy = await _getPolicy(enrollment.policy_slug);
         if (!policy) {
           // Policy went missing between enrollment + tick — close
@@ -645,6 +662,24 @@ function create(opts) {
       var attemptCount  = Number(enrollment.attempt_count);
       var nextAttempt   = attemptCount + 1;
 
+      // Atomic claim: bump attempt_count gated on the value we observed,
+      // BEFORE writing the attempt ledger row. The status check above
+      // only refuses a SEQUENTIAL re-record once the row is terminal;
+      // two concurrent recordRetryOutcome calls while still active (a
+      // webhook redelivery, or a manual record racing the webhook) would
+      // both read attempt_count=N, both write a duplicate attempt row,
+      // and both double-count toward the cap. Only the caller whose
+      // UPDATE matches one row proceeds; a loser returns the
+      // already-advanced row idempotently.
+      var outcomeClaim = await query(
+        "UPDATE payment_retry_enrollments SET attempt_count = ?1 " +
+        "WHERE id = ?2 AND status = 'active' AND attempt_count = ?3",
+        [nextAttempt, enrollment.id, attemptCount],
+      );
+      if (Number(outcomeClaim.rowCount || 0) !== 1) {
+        return await _refetchEnrollment(enrollment.id);
+      }
+
       await _writeAttempt(enrollment.id, nextAttempt, succeeded, succeeded ? null : newFailureCode);
 
       if (succeeded) {

package/lib/pick-lists.js

@@ -548,31 +548,69 @@ function create(opts) {
         }
         perOrder[oid].push(list.lines[k]);
       }
-      var shipments = [];
-      for (var m = 0; m < orderSeq.length; m += 1) {
-        var ord = orderSeq[m];
-        // A picked-from-shelf parcel has no carrier yet — the operator
-        // assigns one when they hand it off. orderTracking's carrier enum
-        // doesn't carry a "pickup" / "none" value, so the parcel rides the
-        // 'other' escape hatch with a "pickup" label until a real carrier
-        // is recorded against it (the operator updates the shipment, or a
-        // shipping-label record supplies the carrier).
-        var s = await orderTracking.createShipment({
-          order_id:           ord,
-          carrier:            "other",
-          carrier_other_name: "pickup",
-          notes:              "pick-list:" + listId,
-        });
-        shipments.push({
-          order_id:    ord,
-          shipment_id: s.id,
-        });
-      }
+
+      // Atomically claim completion BEFORE fanning out any shipment.
+      // The JS status check above is necessary (it produces the
+      // operator-facing "list is <status>" refusal) but NOT sufficient:
+      // two concurrent markListComplete callers both read 'in_progress'
+      // and would each run the createShipment loop, double-creating one
+      // shipment per parent order. The conditional UPDATE — guarded by
+      // the same precondition in its own WHERE — is the atomic claim
+      // (SQLite/D1 serializes writers, so exactly one UPDATE matches a
+      // row in an eligible state). The loser sees rowCount===0 and
+      // refuses; only the winner proceeds to createShipment.
       var ts = _now();
-      await query(
-        "UPDATE pick_lists SET status = 'complete', completed_at = ?1 WHERE id = ?2",
+      var claim = await query(
+        "UPDATE pick_lists SET status = 'complete', completed_at = ?1 " +
+        "WHERE id = ?2 AND status IN ('generated', 'in_progress')",
         [ts, listId],
       );
+      if (Number(claim.rowCount || 0) !== 1) {
+        // Lost the race (or the row left an eligible state between the
+        // read and the claim). Surface the same terminal-state refusal
+        // a sequential caller would see — the shipments belong to the
+        // caller that won the claim.
+        throw new TypeError("pick-lists.markListComplete: list is no longer " +
+          "generated or in_progress (already completed or cancelled by a concurrent caller)");
+      }
+
+      var shipments = [];
+      try {
+        for (var m = 0; m < orderSeq.length; m += 1) {
+          var ord = orderSeq[m];
+          // A picked-from-shelf parcel has no carrier yet — the operator
+          // assigns one when they hand it off. orderTracking's carrier enum
+          // doesn't carry a "pickup" / "none" value, so the parcel rides the
+          // 'other' escape hatch with a "pickup" label until a real carrier
+          // is recorded against it (the operator updates the shipment, or a
+          // shipping-label record supplies the carrier).
+          var s = await orderTracking.createShipment({
+            order_id:           ord,
+            carrier:            "other",
+            carrier_other_name: "pickup",
+            notes:              "pick-list:" + listId,
+          });
+          shipments.push({
+            order_id:    ord,
+            shipment_id: s.id,
+          });
+        }
+      } catch (e) {
+        // The side-effect threw after the claim landed. Revert the claim
+        // (self-targeting WHERE so we only undo a row WE moved to
+        // 'complete') so the list isn't stranded terminal with a
+        // partial / zero shipment fan-out — the operator can retry once
+        // the createShipment fault clears.
+        try {
+          await query(
+            "UPDATE pick_lists SET status = ?1, completed_at = NULL " +
+            "WHERE id = ?2 AND status = 'complete'",
+            [list.status, listId],
+          );
+        } catch (_e) { /* drop-silent — the original createShipment error is what the operator needs */ }
+        throw e;
+      }
+
       var hydrated = await _getHydrated(listId);
       hydrated.shipments = shipments;
       return hydrated;

package/lib/plan-changes.js

@@ -382,6 +382,10 @@ function create(opts) {
               period_end:      sub.current_period_end,
               amount_minor:    net,
               currency:        proposed.currency.toUpperCase(),
+              // Deterministic idempotency key keyed on this change row so
+              // a re-applied change dedupes against the UNIQUE
+              // processor_invoice_id instead of double-billing.
+              processor_invoice_id: "planchange:" + id,
             });
           } catch (_e) {
             // Drop-silent — by design. The billing handle is an
@@ -468,10 +472,21 @@ function create(opts) {
       var executed = [];
       for (var i = 0; i < due.rows.length; i += 1) {
         var row = due.rows[i];
-        await query(
-          "UPDATE subscription_plan_changes SET status = 'executed', executed_at = ?1 WHERE id = ?2",
+        // Atomic claim: flip pending -> executed gated on the status.
+        // Two overlapping scheduler runs (cron overrun, retry, two
+        // workers) both SELECT the same due row; WITHOUT this guard both
+        // would update the subscription plan AND record a proration
+        // invoice — billing the customer twice for one change. Only the
+        // caller whose UPDATE matches one row proceeds; the loser skips.
+        // (The synchronous executeChange path is already protected by its
+        // plan_id claim; this is the batch path's equivalent.)
+        var claim = await query(
+          "UPDATE subscription_plan_changes SET status = 'executed', executed_at = ?1 " +
+          "WHERE id = ?2 AND status = 'pending'",
           [now, row.id],
         );
+        if (Number(claim.rowCount || 0) !== 1) continue;   // another run claimed it
+
         await query(
           "UPDATE subscriptions SET plan_id = ?1, updated_at = ?2 WHERE id = ?3",
           [row.to_plan_id, now, row.subscription_id],
@@ -492,6 +507,10 @@ function create(opts) {
               period_end:      periodEnd,
               amount_minor:    net,
               currency:        String(row.currency).toUpperCase(),
+              // Deterministic idempotency key — this change applies once,
+              // so a re-run dedupes against the UNIQUE processor_invoice_id
+              // rather than writing a second proration invoice.
+              processor_invoice_id: "planchange:" + row.id,
             });
           } catch (_e) {
             // Drop-silent — see executeChange.