@blamejs/blamejs-shop 0.4.61 → 0.4.62

package/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- 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.62",
   "assets": {
     "css/admin.css": {
       "integrity": "sha384-imfe0otYErcB8rr2h6KLSGTtStirysptpXETSPY4zLv3bZoIT75Lo1dOvkOav+xL",

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/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/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.

package/lib/seller-signup.js

@@ -842,6 +842,29 @@ function create(opts) {
         throw notReady;
       }
 
+      // Atomic claim FIRST: flip in_review -> approved gated on the
+      // status. The JS checks above only refuse a sequential re-approve;
+      // two concurrent approvals would both read 'in_review', both pass,
+      // and both call registerVendor — which mints a fresh vendor row
+      // each time, leaving a DUPLICATE vendor for one application. The
+      // `AND status = 'in_review'` predicate lets exactly one caller win;
+      // the loser is refused before registering anything. vendor_slug is
+      // stamped in a second UPDATE after the (winner-only) registration.
+      var ts = _now();
+      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],
+      );
+      if (Number(claim.rowCount || 0) !== 1) {
+        var raced = new Error(
+          "seller-signup.approveApplication: refused — application is no longer in_review (concurrent approval)"
+        );
+        raced.code = "APPLICATION_NOT_READY";
+        throw raced;
+      }
+
       // Compose vendors.registerVendor — the operator-facing v1
       // defaults a fresh marketplace seller to bank_transfer payout +
       // 70% commission split; the operator tunes both via
@@ -860,6 +883,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.
+        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],
+          );
+        } catch (_e2) { /* drop-silent — the registerVendor error is the caller's signal */ }
         // Surface the vendors error with our typed-code wrapper so
         // operators can distinguish a vendors-layer refusal from an
         // application-layer refusal.
@@ -872,13 +906,10 @@ function create(opts) {
         throw wrapped;
       }
 
-      var ts = _now();
+      // Stamp the registered vendor slug onto the now-approved application.
       await query(
-        "UPDATE seller_applications " +
-        "SET status = 'approved', approved_at = ?1, approved_by = ?2, " +
-        "    vendor_slug = ?3, updated_at = ?1 " +
-        "WHERE id = ?4",
-        [ts, approvedBy, vendor.slug, applicationId],
+        "UPDATE seller_applications SET vendor_slug = ?1, updated_at = ?2 WHERE id = ?3",
+        [vendor.slug, _now(), applicationId],
       );
 
       return {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/blamejs-shop",
-  "version": "0.4.61",
+  "version": "0.4.62",
   "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": {