@blamejs/blamejs-shop 0.4.63 → 0.4.64

package/CHANGELOG.md

@@ -8,6 +8,8 @@ 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.

package/lib/asset-manifest.json

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

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/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/reorder-reminders.js

@@ -561,16 +561,20 @@ function create(opts) {
             fail_reason:   null,
           }));
         } else {
-          // The send failed after we won the claim. Roll the cursor
-          // back to the observed value so the retry sweep picks this
-          // row up on the next tick (failed rows stay due — matching
-          // the single-caller contract). The rollback is guarded on
-          // the value we set so a concurrent re-enrolment that moved
-          // the cursor forward in the meantime isn't clobbered.
+          // The send failed after we won the claim. Roll the cursor to a
+          // value DISTINCT from the one this tick observed (observed + 1ms),
+          // NOT back to the exact observed value: a concurrent overlapping
+          // tick that read the same observed cursor is waiting to claim
+          // `next_remind_at = observed`, and restoring the exact observed
+          // value would let it match and re-send in the same overlap.
+          // observed+1 is still <= now, so the row stays due and a LATER
+          // tick retries it (deferred, not re-fired in this overlap). The
+          // guard on the value we set means a concurrent re-enrolment that
+          // moved the cursor forward isn't clobbered.
           await query(
             "UPDATE reorder_enrollments SET next_remind_at = ?1 " +
             "WHERE id = ?2 AND next_remind_at = ?3",
-            [enrollment.next_remind_at, enrollment.id, nextRemindAt],
+            [enrollment.next_remind_at + 1, enrollment.id, nextRemindAt],
           );
           await query(
             "INSERT INTO reorder_dispatches (id, enrollment_id, status, occurred_at, fail_reason) " +

package/lib/seller-signup.js

@@ -826,14 +826,21 @@ function create(opts) {
         miss.code = "APPLICATION_NOT_FOUND";
         throw miss;
       }
-      if (TERMINAL_APPLICATION_STATUSES.indexOf(app.status) !== -1) {
+      // A stranded approval: a prior approve claimed 'approved' but the
+      // vendor was never persisted (the worker died / timed out between
+      // the status claim and the vendor_slug stamp). 'approved' is
+      // terminal, so without this the application could never be approved,
+      // rejected, or revised again. Treat an 'approved' row with no
+      // vendor_slug as re-approvable so the registration can be retried.
+      var recoverable = app.status === "approved" && app.vendor_slug == null;
+      if (TERMINAL_APPLICATION_STATUSES.indexOf(app.status) !== -1 && !recoverable) {
         var term = new Error(
           "seller-signup.approveApplication: refused — application is " + app.status + " (terminal)"
         );
         term.code = "APPLICATION_TERMINAL";
         throw term;
       }
-      if (app.status !== "in_review") {
+      if (app.status !== "in_review" && !recoverable) {
         var notReady = new Error(
           "seller-signup.approveApplication: refused — application is " + app.status +
           "; approve requires status='in_review' (all requested documents uploaded)"
@@ -851,15 +858,25 @@ function create(opts) {
       // the loser is refused before registering anything. vendor_slug is
       // stamped in a second UPDATE after the (winner-only) registration.
       var ts = _now();
+      // The recovery branch (re-approving a stranded 'approved' row with
+      // no vendor) must be EXCLUSIVE. Without gating on the observed
+      // approved_at, two concurrent recovery approvals would BOTH match
+      // (the UPDATE changes nothing that makes the recoverable predicate
+      // false) and both call registerVendor — the duplicate-vendor race
+      // the claim exists to prevent. Gating the recovery branch on
+      // `approved_at = <observed>` (while the UPDATE bumps approved_at to
+      // a fresh ts) makes a second concurrent caller's predicate no longer
+      // match. The in_review branch stays exclusive via the status flip.
       var claim = await query(
         "UPDATE seller_applications " +
         "SET status = 'approved', approved_at = ?1, approved_by = ?2, updated_at = ?1 " +
-        "WHERE id = ?3 AND status = 'in_review'",
-        [ts, approvedBy, applicationId],
+        "WHERE id = ?3 AND (status = 'in_review' " +
+        "OR (status = 'approved' AND vendor_slug IS NULL AND approved_at = ?4))",
+        [ts, approvedBy, applicationId, app.approved_at],
       );
       if (Number(claim.rowCount || 0) !== 1) {
         var raced = new Error(
-          "seller-signup.approveApplication: refused — application is no longer in_review (concurrent approval)"
+          "seller-signup.approveApplication: refused — application is not in an approvable state (concurrent approval)"
         );
         raced.code = "APPLICATION_NOT_READY";
         throw raced;
@@ -883,15 +900,17 @@ function create(opts) {
           status:               "active",
         });
       } catch (e) {
-        // Roll the claim back so the application returns to in_review and
-        // can be re-approved — the winning claim must not strand the app
-        // in 'approved' with no vendor behind it.
+        // Roll back ONLY the claim THIS call won, to in_review so it can be
+        // re-approved. Gate on `approved_at = ts` (our claim's stamp, never
+        // a subsequent re-claim's) AND `vendor_slug IS NULL` (no vendor was
+        // stamped) so a delayed rollback can't clobber another caller's
+        // successful approval.
         try {
           await query(
             "UPDATE seller_applications " +
             "SET status = 'in_review', approved_at = NULL, approved_by = NULL, updated_at = ?1 " +
-            "WHERE id = ?2 AND status = 'approved'",
-            [_now(), applicationId],
+            "WHERE id = ?2 AND status = 'approved' AND approved_at = ?3 AND vendor_slug IS NULL",
+            [_now(), applicationId, ts],
           );
         } catch (_e2) { /* drop-silent — the registerVendor error is the caller's signal */ }
         // Surface the vendors error with our typed-code wrapper so

package/lib/wishlist-digest.js

@@ -941,10 +941,19 @@ function create(opts) {
       // the cursor back to observedNext, guarded on the value we claimed
       // so a concurrent winner's advance is never clobbered.
       var _unclaim = async function () {
+        // Roll the cursor to a value DISTINCT from the one this tick
+        // observed (observedNext + 1ms), NOT back to the exact observed
+        // value: a concurrent overlapping tick that read the same cursor
+        // is waiting to claim `next_dispatch_at = observedNext`, and
+        // restoring the exact value would let it match and re-send the
+        // digest in the same overlap. observedNext+1 stays due, so a LATER
+        // tick re-attempts (deferred, not re-fired in this overlap); the
+        // guard on the claimed value means a concurrent winner's advance
+        // is never clobbered.
         await query(
           "UPDATE wishlist_digest_enrollments SET next_dispatch_at = ?1 " +
           "WHERE id = ?2 AND next_dispatch_at = ?3",
-          [observedNext, enrollment.id, nextDispatchAt],
+          [observedNext + 1, enrollment.id, nextDispatchAt],
         );
       };
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/blamejs-shop",
-  "version": "0.4.63",
+  "version": "0.4.64",
   "description": "Open-source framework built on blamejs. Vendored stack, zero npm runtime deps, PQC-first crypto, security-on by default.",
   "main": "lib/index.js",
   "scripts": {