@blamejs/blamejs-shop 0.4.60 → 0.4.61

package/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- 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.61",
   "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/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/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.61",
   "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": {