@blamejs/blamejs-shop 0.4.60 → 0.4.62

package/CHANGELOG.md

@@ -8,6 +8,10 @@ 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.
 
 - v0.4.59 (2026-06-19) — **Win-back campaign sends now actually run (they were being silently blocked).** Fixes a defect that left win-back campaigns completely inert since they shipped: the scheduled worker tick that drives win-back enrolment and dispatch was being rejected by the application bot-guard before it could reach its own shared-secret gate, so no win-back step ever sent. The worker fires its internal cron ticks machine-to-machine with only a content type and the bridge-secret header — no browser fingerprint — and the bot-guard's missing-Accept-Language heuristic returned 403 for the win-back path. Every other internal cron tick (cart-recovery, stock-alert and low-stock sweeps, wishlist alerts and digests, campaign send, customer-portal expiry, stale-order reap, quote expiry) was already exempt from the bot-guard; the win-back tick was the one omission. It is now exempt as well, so the tick reaches its handler (still gated by the bridge secret), and an operator who has win-back configured now sees the escalating offer sequence actually go out. A new test asserts every internal cron path is exempt from the bot-guard, so a future cron-driven feature can't ship blocked the same way. **Fixed:** *Win-back campaign cron tick was blocked by the bot-guard* — The internal /_/winback-send-tick POST the worker fires on a schedule was missing from the bot-guard exemption list, so the application bot-guard returned 403 on the missing-Accept-Language heuristic before the handler's bridge-secret check ran. Win-back enrolment and step dispatch therefore never executed. The path is now exempt like the other nine internal cron ticks (the bridge-secret gate remains the deciding check, so an unauthenticated caller is still refused). A bot-guard skip-list parity test now asserts every internal cron path is exempt, anchored to the security middleware so it runs in the container image too — closing the gap that let this ship.

package/lib/asset-manifest.json

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

package/lib/customer-surveys.js

@@ -727,16 +727,33 @@ function create(opts) {
 
     var canonicalAnswers = _validateAnswers(input.answers, questions);
 
+    // Atomic claim: flip 'issued' -> 'responded' guarded by the
+    // observed status in the WHERE before recording the response. The
+    // JS status checks above give precise typed errors for the
+    // sequential case, but two concurrent submits on the same token
+    // both pass those checks (each reads status='issued'); only this
+    // conditional UPDATE can win. SQLite/D1 serializes writers, so
+    // exactly one submit sees rowCount===1 and is allowed to INSERT
+    // the response row — the loser sees rowCount===0 and refuses,
+    // so the response is recorded exactly once (no duplicate
+    // survey_responses row, no double-counted rollup).
+    var claim = await query(
+      "UPDATE survey_invitations SET status = 'responded', responded_at = ?1 " +
+      "WHERE id = ?2 AND status = 'issued'",
+      [nowTs, invitation.id],
+    );
+    if (Number(claim.rowCount || 0) !== 1) {
+      var raced = new Error("customerSurveys.submitResponse: invitation already responded");
+      raced.code = "SURVEY_INVITATION_ALREADY_RESPONDED";
+      throw raced;
+    }
+
     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],
     );
-    await query(
-      "UPDATE survey_invitations SET status = 'responded', responded_at = ?1 WHERE id = ?2",
-      [nowTs, invitation.id],
-    );
 
     return {
       response_id:    responseId,

package/lib/dunning.js

@@ -390,6 +390,34 @@ function create(opts) {
   // The function is the heart of tickDunning — it's surfaced
   // internally so tests can drive a single advance deterministically.
   async function _advance(enrollment, schedule, cancelAfterAttempts, now) {
+    // ---- atomic claim ----------------------------------------------
+    // tickDunning snapshots the due-set with a SELECT, then walks each
+    // row here. Two concurrent ticks (overlapping cron fires, a manual
+    // tick racing the cron) both see the SAME due row and would each
+    // run _executeAction — double-emailing the customer, double-
+    // recording the retry, double-pausing/cancelling the subscription.
+    // SQLite/D1 serializes writers, so a conditional UPDATE is the
+    // atomic claim: null out next_action_at guarded on the value this
+    // tick OBSERVED (enrollment.next_action_at) AND status='active'.
+    // The first tick to land flips it to 1 row; the loser matches 0
+    // rows and skips the row entirely (returns the row unchanged so
+    // the snapshot caller still gets a refreshed view without firing
+    // the side-effect twice). The subsequent state UPDATEs below all
+    // re-assert status='active' so a unsetEnrollment landing mid-walk
+    // can't be clobbered back to active either.
+    var observedNextAt = enrollment.next_action_at;
+    var claim = await query(
+      "UPDATE dunning_enrollments SET next_action_at = NULL " +
+      "WHERE id = ?1 AND status = 'active' AND next_action_at = ?2",
+      [enrollment.id, observedNextAt],
+    );
+    if (Number(claim.rowCount || 0) !== 1) {
+      // Lost the race — another tick already claimed this row (or it
+      // was unset to a terminal status between the snapshot and now).
+      // Skip the side-effect; return the current row state.
+      return await _refetchEnrollment(enrollment.id);
+    }
+
     var attemptCount = Number(enrollment.attempt_count);
     var stepIndex    = attemptCount;
     if (stepIndex >= schedule.length) {
@@ -401,7 +429,7 @@ function create(opts) {
       await query(
         "UPDATE dunning_enrollments SET status = ?1, next_action_at = NULL, " +
         "ended_at = ?2, end_reason = ?3, last_action = ?4, last_action_at = ?2 " +
-        "WHERE id = ?5",
+        "WHERE id = ?5 AND status = 'active'",
         [closeAs, now, "schedule_exhausted", "schedule_exhausted", enrollment.id],
       );
       await _writeEvent(enrollment.id, attemptCount, "cancel_subscription", "ok", now);
@@ -419,7 +447,7 @@ function create(opts) {
       await query(
         "UPDATE dunning_enrollments SET status = 'cancelled', next_action_at = NULL, " +
         "attempt_count = ?1, last_action = ?2, last_action_at = ?3, " +
-        "ended_at = ?3, end_reason = ?4 WHERE id = ?5",
+        "ended_at = ?3, end_reason = ?4 WHERE id = ?5 AND status = 'active'",
         [newAttemptCount, action, now, action === "cancel_subscription" ? "policy_cancel_step" : "attempt_cap", enrollment.id],
       );
       await _writeEvent(enrollment.id, newAttemptCount, action, outcome, now);
@@ -433,7 +461,7 @@ function create(opts) {
       await query(
         "UPDATE dunning_enrollments SET status = 'abandoned', next_action_at = NULL, " +
         "attempt_count = ?1, last_action = ?2, last_action_at = ?3, " +
-        "ended_at = ?3, end_reason = 'schedule_exhausted' WHERE id = ?4",
+        "ended_at = ?3, end_reason = 'schedule_exhausted' WHERE id = ?4 AND status = 'active'",
         [newAttemptCount, action, now, enrollment.id],
       );
       await _writeEvent(enrollment.id, newAttemptCount, action, outcome, now);
@@ -442,7 +470,7 @@ function create(opts) {
 
     await query(
       "UPDATE dunning_enrollments SET attempt_count = ?1, last_action = ?2, " +
-      "last_action_at = ?3, next_action_at = ?4 WHERE id = ?5",
+      "last_action_at = ?3, next_action_at = ?4 WHERE id = ?5 AND status = 'active'",
       [newAttemptCount, action, now, planned.next_action_at, enrollment.id],
     );
     await _writeEvent(enrollment.id, newAttemptCount, action, outcome, now);

package/lib/email-campaigns.js

@@ -1187,10 +1187,26 @@ function create(opts) {
         );
       }
       await _fire(row, "start");
-      await query(
-        "UPDATE email_campaigns SET status = 'sending', updated_at = ?1 WHERE slug = ?2",
+      // Atomic claim: the scheduled → sending flip is the exactly-once
+      // gate on the drain. `_fire` only validates the FSM against the
+      // row we read — two concurrent sendNow / dispatchTick calls can
+      // both read `scheduled`, both pass that in-memory check, and both
+      // reach the drain, double-mailing the whole audience. Guarding the
+      // SET on the OBSERVED status makes exactly one caller win the flip;
+      // SQLite serializes the writers so only one UPDATE reports a row
+      // changed. The loser refuses rather than drains.
+      var claim = await query(
+        "UPDATE email_campaigns SET status = 'sending', updated_at = ?1 " +
+        "WHERE slug = ?2 AND status = 'scheduled'",
         [Date.now(), slug],
       );
+      if (Number(claim.rowCount || 0) !== 1) {
+        var raceErr = new TypeError(
+          "emailCampaigns.sendNow: campaign '" + slug + "' is already being sent"
+        );
+        raceErr.code = "EMAIL_CAMPAIGN_SEND_RACE";
+        throw raceErr;
+      }
       var stats = await _drainSend(row);
       // Re-fire complete off the freshly-read row so the FSM sees the
       // 'sending' state we just wrote.
@@ -1233,10 +1249,18 @@ function create(opts) {
           // picked it up. Skip; the row is no longer scheduled.
           continue;
         }
-        await query(
-          "UPDATE email_campaigns SET status = 'sending', updated_at = ?1 WHERE slug = ?2",
+        // Atomic claim: `_fire` only validated the FSM against the
+        // snapshot row this tick SELECTed, so two concurrent ticks (or a
+        // tick racing sendNow) can both pass that check and both drain —
+        // double-mailing the audience. Guarding the SET on the observed
+        // `scheduled` status lets exactly one writer win the flip; the
+        // loser skips this row instead of re-sending.
+        var claim = await query(
+          "UPDATE email_campaigns SET status = 'sending', updated_at = ?1 " +
+          "WHERE slug = ?2 AND status = 'scheduled'",
           [Date.now(), row.slug],
         );
+        if (Number(claim.rowCount || 0) !== 1) continue;
         var stats = await _drainSend(row);
         var midRow = await _getRow(row.slug);
         await _fire(midRow, "complete");
@@ -1546,10 +1570,25 @@ function create(opts) {
           );
         }
         await _fire(row, "start");
-        await query(
-          "UPDATE email_campaigns SET status = 'sending', updated_at = ?1 WHERE slug = ?2",
+        // Atomic claim on the scheduled → sending flip. The per-recipient
+        // email_campaign_sends ledger already dedupes individual mails on
+        // a resumed drain, but two concurrent broadcasts that both read
+        // `scheduled` would both enter the drain and contend on that
+        // ledger; guarding the flip on the observed status lets exactly
+        // one caller take the campaign into `sending`. The loser refuses
+        // (broadcastTick's per-campaign catch turns this into a skip).
+        var claim = await query(
+          "UPDATE email_campaigns SET status = 'sending', updated_at = ?1 " +
+          "WHERE slug = ?2 AND status = 'scheduled'",
           [Date.now(), slug],
         );
+        if (Number(claim.rowCount || 0) !== 1) {
+          var raceErr = new TypeError(
+            "emailCampaigns.broadcast: campaign '" + slug + "' is already being sent"
+          );
+          raceErr.code = "EMAIL_CAMPAIGN_SEND_RACE";
+          throw raceErr;
+        }
         row = await _getRow(slug);
       }
 

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/push-notifications.js

@@ -810,18 +810,31 @@ function create(opts) {
         var providerSlug = row.provider_slug;
         var provider = providerSlug ? await _getProvider(providerSlug) : null;
         if (!provider || Number(provider.active) !== 1 || provider.archived_at != null) {
-          await query(
+          // Atomic claim. The snapshot SELECT above is read without a
+          // lock, so two concurrent ticks can both pull this same
+          // `queued` row. The `AND status = 'queued'` guard makes the
+          // transition the claim: SQLite/D1 serialises writers, so
+          // exactly one tick's UPDATE matches the row (rowCount === 1)
+          // and the other sees rowCount === 0. Only the winner hands
+          // the row to the operator's send hook (via `advanced`), so
+          // the customer is never double-dispatched.
+          var lostFail = await query(
             "UPDATE push_notifications SET status = 'failed', fail_reason = ?1, " +
-            "failed_at = ?2 WHERE id = ?3",
+            "failed_at = ?2 WHERE id = ?3 AND status = 'queued'",
             ["provider_unavailable_at_dispatch", now, row.id],
           );
+          if (Number(lostFail.rowCount || 0) !== 1) continue;
           advanced.push(await _getNotification(row.id));
           continue;
         }
-        await query(
-          "UPDATE push_notifications SET status = 'sent', dispatched_at = ?1 WHERE id = ?2",
+        // Atomic claim on the advance to `sent` — same race, same
+        // guard. The loser skips so the send hook fires once per row.
+        var claimed = await query(
+          "UPDATE push_notifications SET status = 'sent', dispatched_at = ?1 " +
+          "WHERE id = ?2 AND status = 'queued'",
           [now, row.id],
         );
+        if (Number(claimed.rowCount || 0) !== 1) continue;
         advanced.push(await _getNotification(row.id));
       }
       return advanced;

package/lib/reorder-reminders.js

@@ -520,6 +520,29 @@ function create(opts) {
           continue;
         }
 
+        // Claim this row BEFORE sending. The send (email/sms/in_app)
+        // is an exactly-once side-effect; two concurrent ticks both
+        // read this same due row from the snapshot SELECT above and
+        // would both fire it. Advancing next_remind_at conditionally
+        // on the value we observed (next_remind_at = the snapshot's
+        // value) is the atomic claim — SQLite/D1 serializes writers,
+        // so exactly one tick's UPDATE matches and the loser sees
+        // rowCount 0 and skips the send. We claim by advancing one
+        // interval from the OBSERVED next_remind_at (not `now`) so a
+        // late tick doesn't drift the cadence forward.
+        var nextRemindAt = enrollment.next_remind_at + profile.interval_days * DAY_MS;
+        var claim = await query(
+          "UPDATE reorder_enrollments SET next_remind_at = ?1 " +
+          "WHERE id = ?2 AND status = 'active' AND next_remind_at = ?3",
+          [nextRemindAt, enrollment.id, enrollment.next_remind_at],
+        );
+        if (Number(claim.rowCount || 0) !== 1) {
+          // Another tick already advanced this row's cursor (or it was
+          // cancelled between the SELECT and now) — it owns the send.
+          // Skip without dispatching so the customer is nudged once.
+          continue;
+        }
+
         var result = await _dispatchOne(enrollment, profile);
         var occurredAt = _now();
         if (result.ok) {
@@ -528,14 +551,8 @@ function create(opts) {
             "VALUES (?1, ?2, 'sent', ?3, NULL)",
             [dispatchId, enrollment.id, occurredAt],
           );
-          // Advance next_remind_at by one interval from the current
-          // next_remind_at (not from `now`) so a late dispatcher tick
-          // doesn't drift the cadence forward.
-          var nextRemindAt = enrollment.next_remind_at + profile.interval_days * DAY_MS;
-          await query(
-            "UPDATE reorder_enrollments SET next_remind_at = ?1 WHERE id = ?2",
-            [nextRemindAt, enrollment.id],
-          );
+          // Cadence already advanced by the claim above; the send
+          // succeeded, so the row stays at the new next_remind_at.
           dispatched.push(_shapeDispatch({
             id:            dispatchId,
             enrollment_id: enrollment.id,
@@ -544,6 +561,17 @@ 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.
+          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],
+          );
           await query(
             "INSERT INTO reorder_dispatches (id, enrollment_id, status, occurred_at, fail_reason) " +
             "VALUES (?1, ?2, 'failed', ?3, ?4)",

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/lib/wishlist-digest.js

@@ -900,6 +900,54 @@ function create(opts) {
       }
       var schedule = _shapeSchedule(scheduleRow);
 
+      // ---- ATOMIC CLAIM ------------------------------------------------
+      //
+      // The send + sent-ledger INSERT below are an EXACTLY-ONCE side
+      // effect. Two concurrent ticks both read this row from their own
+      // snapshot SELECT, both pass the JS checks, and — without a claim —
+      // both would email the customer and both would ledger a sent row.
+      // SQLite/D1 serializes writers, so a conditional UPDATE that
+      // advances the cursor on the OBSERVED next_dispatch_at IS the claim:
+      // exactly one tick flips next_dispatch_at away from `observedNext`,
+      // and only the winner (rowCount === 1) runs the side effect. The
+      // loser (rowCount === 0) lost the race — skip silently (no email,
+      // no ledger row). The new cursor matches what the post-send advance
+      // used to write, so a single sequential caller is unaffected.
+      var observedNext = Number(enrollment.next_dispatch_at);
+      // Advance the cadence one period past the claimed next_dispatch_at.
+      // A STALE enrollment (cron was down / enrolled long ago) sits many
+      // periods in the past; one period still doesn't clear `now`, so the
+      // next tick would re-fire — a flood. When one period still doesn't
+      // clear `now`, snap straight to the next occurrence strictly after
+      // `now`. The catch-up costs at most ONE digest, never a storm.
+      var nextDispatchAt = _advanceByOnePeriod(schedule, observedNext);
+      if (nextDispatchAt <= now) {
+        nextDispatchAt = _nextDispatchAt(schedule, now);
+      }
+      var claim = await query(
+        "UPDATE wishlist_digest_enrollments SET next_dispatch_at = ?1 " +
+        "WHERE id = ?2 AND status = 'active' AND next_dispatch_at = ?3",
+        [nextDispatchAt, enrollment.id, observedNext],
+      );
+      if (Number(claim.rowCount || 0) !== 1) {
+        // Another tick already claimed this period — don't double-send.
+        continue;
+      }
+
+      // Un-claim helper. The claim advanced next_dispatch_at before we
+      // knew whether the send would succeed; a TRANSIENT failure (compose
+      // threw, no email yet, mailer down) must leave the row due again so
+      // a future tick re-attempts — exactly the pre-claim behavior. Roll
+      // the cursor back to observedNext, guarded on the value we claimed
+      // so a concurrent winner's advance is never clobbered.
+      var _unclaim = async function () {
+        await query(
+          "UPDATE wishlist_digest_enrollments SET next_dispatch_at = ?1 " +
+          "WHERE id = ?2 AND next_dispatch_at = ?3",
+          [observedNext, enrollment.id, nextDispatchAt],
+        );
+      };
+
       // Compose the digest body. composeDigest does its own reads
       // against wishlist + catalog; failures inside it bubble up here
       // and the dispatcher logs the row as skipped so a flapping
@@ -907,6 +955,7 @@ function create(opts) {
       var digest = null;
       try { digest = await composeDigest({ customer_id: enrollment.customer_id }); }
       catch (_e) {
+        await _unclaim();
         skipped += 1; skippedBy.email_dispatch_failed += 1;
         continue;
       }
@@ -921,6 +970,7 @@ function create(opts) {
         catch (_e2) { customerEmail = null; }
       }
       if (typeof customerEmail !== "string" || !customerEmail.length) {
+        await _unclaim();
         skipped += 1; skippedBy.no_email += 1;
         continue;
       }
@@ -954,6 +1004,7 @@ function create(opts) {
             text:           digest.text,
           });
         } catch (_e4) {
+          await _unclaim();
           skipped += 1; skippedBy.email_dispatch_failed += 1;
           continue;
         }
@@ -963,8 +1014,11 @@ function create(opts) {
         // attempt isn't counted as a successful send.
       }
 
-      // Ledger + advance (both branches — suppressed cadence stays on
+      // Ledger the sent row (both branches — suppressed cadence stays on
       // rails so the customer sees their next-dispatch-ETA roll forward).
+      // The cadence advance already happened in the atomic claim above,
+      // so reaching here means this tick won the race and is the sole
+      // writer of this period's ledger row + side effect.
       var sentId = b.uuid.v7();
       var sentAt = _now(now);
       await query(
@@ -972,24 +1026,6 @@ function create(opts) {
         "VALUES (?1, ?2, ?3, ?4)",
         [sentId, enrollment.id, sentItemCount, sentAt],
       );
-      // Advance the cadence. The normal step is one period past the
-      // current next_dispatch_at — that keeps the schedule aligned to its
-      // target weekday / day-of-month when the tick fires on time. But a
-      // STALE enrollment (the cron was down, or the customer enrolled long
-      // ago) has a next_dispatch_at many periods in the past; advancing it
-      // one period at a time would leave it still due, so the very next
-      // tick re-fires, and a subscriber gets one digest per tick until the
-      // schedule catches up — a flood. Instead, when one period still
-      // doesn't clear `now`, snap straight to the next occurrence strictly
-      // after `now`. The catch-up costs at most ONE digest, never a storm.
-      var nextDispatchAt = _advanceByOnePeriod(schedule, Number(enrollment.next_dispatch_at));
-      if (nextDispatchAt <= now) {
-        nextDispatchAt = _nextDispatchAt(schedule, now);
-      }
-      await query(
-        "UPDATE wishlist_digest_enrollments SET next_dispatch_at = ?1 WHERE id = ?2",
-        [nextDispatchAt, enrollment.id],
-      );
       if (!isSuppressed) {
         dispatched.push({
           id:               sentId,

package/package.json

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