@blamejs/blamejs-shop 0.4.62 → 0.4.64

package/CHANGELOG.md

@@ -8,6 +8,10 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- v0.4.64 (2026-06-19) — **A failed side-effect can no longer strand a claimed record.** Hardens the atomic-claim concurrency fixes (shipped over the previous releases) against the case where the side-effect fails or the worker crashes AFTER a record was claimed. Each claim now restores or recovers the record so a transient failure can't leave it permanently stuck. A scheduled payment retry that is claimed out of the due set but then fails to advance (a malformed policy or a database write error) restores its next-retry time, so the retry isn't silently dropped. Approving a seller application that crashes between claiming the approval and persisting the vendor is now recoverable — an application left approved with no vendor can be approved again rather than being stranded in a terminal state. A survey response whose insert fails after the invitation was claimed reverts the invitation to issued so it can be answered. A reorder reminder or wishlist digest whose send fails defers the retry to a later tick on a distinct cursor, so a concurrent overlapping tick can't pick up the rolled-back row and send a duplicate in the same window. No API change. **Fixed:** *Payment retry restores its schedule on a failed advance* — The retry scheduler claims an enrollment out of the due set by clearing its next-retry time before doing processor work. If advancing the enrollment then throws (a malformed retry policy, or a database write failure while recording the attempt), the next-retry time is restored to the value the tick observed, so a later tick re-attempts the retry. Previously the enrollment was left active with no next-retry time, and the due query (which requires a next-retry time) would never pick it up again, silently stopping the customer's recovery retries. · *Seller approval is recoverable after a mid-approval crash* — Approving a seller application claims the in-review-to-approved transition before registering the vendor. If the worker crashes or times out between the claim and persisting the vendor, the application is left approved with no vendor — a terminal state the rest of the primitive could never move out of. Approval now treats an approved application that has no vendor attached as re-approvable, so the registration can be retried and the application recovered instead of stranded. · *Survey response keeps the invitation retryable on insert failure* — Submitting a survey response claims the invitation (issued to responded) before inserting the response row. If that insert fails (a transient write error), the invitation is reverted to issued so the response can be submitted again, rather than being stuck responded with no response recorded and every retry rejected as already-responded. · *Reorder reminder and wishlist digest defer a failed send instead of re-firing it* — When a reorder reminder or a wishlist digest send fails after the row was claimed, the schedule cursor is rolled to a value distinct from the one the tick observed (still due, so a later tick retries) rather than back to the exact observed value. A concurrent overlapping tick that read the same cursor was waiting to claim it; restoring the exact value let it match and send a duplicate in the same window. The retry is now deferred to a later tick with no duplicate.
+
+- 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.

package/lib/asset-manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.4.62",
+  "version": "0.4.64",
   "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/customer-surveys.js

@@ -749,11 +749,26 @@ function create(opts) {
     }
 
     var responseId = b.uuid.v7();
-    await query(
-      "INSERT INTO survey_responses (id, invitation_id, answers_json, occurred_at) " +
-      "VALUES (?1, ?2, ?3, ?4)",
-      [responseId, invitation.id, JSON.stringify(canonicalAnswers), occurredAt],
-    );
+    try {
+      await query(
+        "INSERT INTO survey_responses (id, invitation_id, answers_json, occurred_at) " +
+        "VALUES (?1, ?2, ?3, ?4)",
+        [responseId, invitation.id, JSON.stringify(canonicalAnswers), occurredAt],
+      );
+    } catch (insErr) {
+      // The claim above already flipped the invitation to 'responded'. If
+      // the response insert fails (a transient D1/SQLite write error),
+      // revert the claim to 'issued' so the invitation stays retryable —
+      // otherwise it is stranded 'responded' with no response row and
+      // every retry is rejected as ALREADY_RESPONDED, so the response can
+      // never be recorded.
+      await query(
+        "UPDATE survey_invitations SET status = 'issued', responded_at = NULL " +
+        "WHERE id = ?1 AND status = 'responded'",
+        [invitation.id],
+      );
+      throw insErr;
+    }
 
     return {
       response_id:    responseId,

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

@@ -604,19 +604,50 @@ function create(opts) {
         );
         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
-          // as abandoned so the row doesn't spin forever.
+        // Pre-charge prep. The claim above nulled next_retry_at to take
+        // the row out of the due set; a throw HERE (a missing policy /
+        // malformed retry schedule) is BEFORE any processor work, so it is
+        // safe to restore the observed next_retry_at (only while still
+        // NULL, so a partial re-stamp isn't clobbered) and let a later
+        // tick re-attempt — otherwise the enrollment is stranded active
+        // with next_retry_at NULL and the due SELECT (next_retry_at IS NOT
+        // NULL) never picks it up again.
+        var policy, schedule;
+        try {
+          policy = await _getPolicy(enrollment.policy_slug);
+          if (!policy) {
+            // Policy went missing between enrollment + tick — close
+            // as abandoned so the row doesn't spin forever.
+            await query(
+              "UPDATE payment_retry_enrollments SET status = 'abandoned', next_retry_at = NULL, " +
+              "ended_at = ?1, end_reason = 'policy_missing' WHERE id = ?2",
+              [now, enrollment.id],
+            );
+            advanced.push(await _refetchEnrollment(enrollment.id));
+            continue;
+          }
+          schedule = _parseSchedule(policy.retry_schedule_json);
+        } catch (prepErr) {
           await query(
-            "UPDATE payment_retry_enrollments SET status = 'abandoned', next_retry_at = NULL, " +
-            "ended_at = ?1, end_reason = 'policy_missing' WHERE id = ?2",
-            [now, enrollment.id],
+            "UPDATE payment_retry_enrollments SET next_retry_at = ?1 " +
+            "WHERE id = ?2 AND status = 'active' AND next_retry_at IS NULL",
+            [enrollment.next_retry_at, enrollment.id],
           );
-          advanced.push(await _refetchEnrollment(enrollment.id));
-          continue;
+          throw prepErr;
         }
-        var schedule = _parseSchedule(policy.retry_schedule_json);
+
+        // _tickAdvance composes paymentHandle.retryIntent — the real
+        // card-charge retry — which runs BEFORE the attempt-ledger and
+        // status writes. By the time any throw escapes _tickAdvance the
+        // charge has already been submitted, so DO NOT restore
+        // next_retry_at on such a throw: re-stamping it would let a later
+        // or overlapping tick call retryIntent AGAIN for the same attempt
+        // and double-move money. The enrollment is left active with
+        // next_retry_at NULL for a recovery sweep / operator to advance;
+        // retryIntent is passed attempt_number as its idempotency
+        // dimension, so a conformant handle de-dupes a deliberate
+        // re-attempt at the same number. (Not stranding without a charge
+        // is the prep branch above; not double-charging is here.)
         var refreshed = await _tickAdvance(enrollment, policy, schedule, now);
         advanced.push(refreshed);
       }

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;