@blamejs/blamejs-shop 0.4.65 → 0.4.67

package/CHANGELOG.md

@@ -8,6 +8,10 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- v0.4.67 (2026-06-20) — **Subject-access exports now carry the customer's complete record, not just the first page.** A data-subject access export assembled each domain by reading a single page from that domain's reader. A customer with more than one page in any paginated domain — orders, the loyalty points ledger, product reviews, wishlist entries, survey invitations, or support tickets — silently received a truncated export, which is an incomplete response to a GDPR Article 15 request. Each of those domains is now drained to the end by following the reader's own cursor, so the export carries every row. Readers that already return the whole set in one read (addresses, the consent ledger, subscriptions) were already complete and are unchanged. As part of this, the support-ticket reader keyed on customer id (the one the export uses, since it holds no plaintext email) gained cursor pagination so it can be paged to completion. **Changed:** *supportTickets.listByCustomerId and customerSurveys.invitationsForCustomer return { rows, next_cursor }* — Both customer-scoped readers that the export uses now return a paginated envelope — { rows, next_cursor } — instead of a bare array, so a caller can page a customer's full history to the end. listByCustomerId pages on the (opened_at desc, id desc) tuple (matching the email-keyed listForCustomer); invitationsForCustomer pages on the invitation id. If you call either directly, read the rows off the .rows field and pass the previous next_cursor as the cursor option to continue where the last page ended. **Fixed:** *Access exports drain every paginated domain to completion* — The export now follows each reader's cursor to the end for orders, the loyalty points ledger, product reviews, wishlist entries, survey invitations, and support tickets, concatenating every page. A customer with hundreds of orders or ledger entries receives all of them rather than the most recent hundred. A page-count backstop far above any real per-customer record guards against a misbehaving cursor without ever truncating a genuine export.
+
+- v0.4.66 (2026-06-20) — **Inventory-audit finalization can no longer double-apply its stock adjustments.** Finalizing an inventory audit with apply_adjustments writes one shelf adjustment per counted line, then marks the audit finalized. Two failure modes could move a shelf twice. First, if a later line was refused mid-loop — most commonly a negative variance that would have pushed the shelf below its outstanding paid holds — the audit stayed open, but the lines already adjusted had moved; re-running the finalize re-applied those earlier adjustments on top of themselves. Second, two finalize calls overlapping on the same audit both applied every adjustment before either marked the audit finalized. Finalization now claims the audit's transition to finalized in a single conditional write BEFORE touching any shelf, so exactly one finalize applies the adjustments and a concurrent or duplicate call applies nothing. Each adjustment is applied as the difference between the counted variance and what this audit has already moved, so a retry lands only the not-yet-applied remainder and a recount made before the retry is reflected exactly. A finalize that is refused part-way re-opens the audit so the operator can clear the blocker and retry. No API change. **Fixed:** *Finalization claims the audit before moving any shelf* — The transition that marks an audit finalized now lands in one conditional write, gated on the audit still being open or in progress, BEFORE any stock adjustment is written. Two finalize calls racing the same audit — or a duplicate retry overlapping a still-running finalize — resolve to a single winner that applies the adjustments; the loser writes nothing and returns the computed totals. The claim also freezes the audit's scan lines, so the variances being applied can't change underneath the writer. · *Adjustments reconcile against what already landed* — Each shelf adjustment is applied as the counted variance minus what this audit has already moved for that SKU and location. A finalize refused part-way (a respect-holds floor on one line) re-opens the audit; the retry then applies only the remaining difference instead of re-applying lines that already succeeded, and a recount that changed a line's variance before the retry is corrected to the new value rather than left at the old one.
+
 - v0.4.65 (2026-06-19) — **Dropship-forwarding and scheduled-export status transitions are now claimed atomically.** Closes two status-transition races in modules that validated the transition with the state-machine primitive but then persisted it with an unconditional update keyed only on the row id. Because the state-machine validation runs in process (each request rebuilds the machine from a fresh row), two concurrent transitions on the same row both passed validation and the second write silently clobbered the first — for example a dropship forwarding being marked shipped while a retry marks it failed, or a scheduled export being cancelled while a worker marks it running. Both now gate the write on the row still being in the state that was validated against (the same single-statement compare-and-swap the order and inventory-receipt lifecycles already use), so exactly one transition lands and a concurrent loser is refused rather than overwriting it. No API change. **Fixed:** *Dropship-forwarding transitions claim the from-state* — Every dropship-forwarding lifecycle edge routes through one helper that validated the transition against the state machine and then wrote UPDATE … WHERE id = ?. The write now also requires the row to still be in the state the transition was validated against (… AND status = <from>) and treats a zero-row result as a lost race (a typed refusal), so two concurrent vendor callbacks (e.g. accept racing ship, or a retry) can't both advance the row and silently overwrite each other. · *Scheduled-export status writers claim the from-state* — The four scheduled-export transitions (cancel, mark-running, mark-complete, mark-failed) validated against the export state machine and then wrote keyed only on the export id. Each now gates the write on the observed from-state and refuses on a zero-row result, so a cancel racing a mark-running (or a duplicate worker callback) no longer last-writer-wins into an illegal state. The state machine still enforces the legal-edge validation; the conditional update is the atomic claim.
 
 - 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.

package/lib/asset-manifest.json

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

package/lib/customer-surveys.js

@@ -651,14 +651,30 @@ function create(opts) {
     var custId = _uuid(customerId, "customer_id");
     listOpts = listOpts || {};
     var limit = _limit(listOpts.limit);
-    var r = await query(
-      "SELECT * FROM survey_invitations WHERE customer_id = ?1 " +
-      "ORDER BY issued_at DESC, id DESC LIMIT ?2",
-      [custId, limit],
-    );
+    var cursor = listOpts.cursor;
+    if (cursor != null && (typeof cursor !== "string" || !cursor.length)) {
+      throw new TypeError("customerSurveys.invitationsForCustomer: cursor must be a non-empty string when provided");
+    }
+    var sql = "SELECT * FROM survey_invitations WHERE customer_id = ?1";
+    var params = [custId];
+    var idx = 2;
+    if (cursor != null) {
+      // Cursor is the last-seen invitation id; v7 ids are lexicographically
+      // monotonic (issued_at sits in the prefix), so a single `id < cursor`
+      // over (id DESC) preserves total ordering — the same idiom
+      // responsesForSurvey uses. Returning { rows, next_cursor } lets a
+      // caller that needs the customer's COMPLETE invitation set — the
+      // subject-access export — page to the end instead of stopping at the
+      // first `limit`.
+      sql += " AND id < ?" + idx; params.push(cursor); idx += 1;
+    }
+    sql += " ORDER BY id DESC LIMIT ?" + idx;
+    params.push(limit);
+    var r = await query(sql, params);
     var out = [];
     for (var i = 0; i < r.rows.length; i += 1) out.push(_decodeInvitation(r.rows[i]));
-    return out;
+    var nextCursor = out.length === limit ? out[out.length - 1].id : null;
+    return { rows: out, next_cursor: nextCursor };
   }
 
   // ---- submitResponse ---------------------------------------------------

package/lib/inventory-audits.js

@@ -595,9 +595,12 @@ function create(opts) {
           ", only open or in_progress audits can be finalized");
       }
       var lines = await _getLines(auditId);
+      // PASS 1 — compute each line's variance, persist it (idempotent),
+      // and collect the shelf adjustments to apply. No shelf is touched
+      // yet: the atomic claim below decides who, if anyone, applies them.
       var varianceCount = 0;
       var varianceValueMinor = 0;
-      var adjustmentsWritten = 0;
+      var adjustable = [];
       for (var i = 0; i < lines.length; i += 1) {
         var line = lines[i];
         // recount_qty wins when present; else counted_qty drives.
@@ -611,36 +614,95 @@ function create(opts) {
           varianceCount += 1;
           var unitValue = await _unitValueMinor(line.sku);
           varianceValueMinor += Math.abs(variance) * unitValue;
-          if (applyAdjustments) {
-            // Adjustments only land on lines that carry a
-            // location_code. A whole-audit-summed line (no
-            // location_code) computes variance for the operator's
-            // reconciliation report but does NOT write to
-            // inventory_locations — the catalog-side correction is
-            // the right verb for the single-bucket inventory.
-            if (line.location_code) {
-              await inventoryLocations.adjustStock({
-                sku:           line.sku,
-                location_code: line.location_code,
-                delta:         variance,
-                reason:        "inventory-audit:" + header.slug,
-                // A negative variance shrinks the shelf — guard it from
-                // dropping below the outstanding paid holds for the SKU
-                // so a later commitHold can't be stranded. Positive
-                // variances (credits) ignore the flag.
-                respect_holds: true,
-              });
-              adjustmentsWritten += 1;
-            }
+          // Adjustments only land on lines that carry a location_code. A
+          // whole-audit-summed line (no location_code) computes variance
+          // for the operator's reconciliation report but does NOT write
+          // to inventory_locations — the catalog-side correction is the
+          // right verb for the single-bucket inventory.
+          if (applyAdjustments && line.location_code) {
+            adjustable.push({ sku: line.sku, location_code: line.location_code, variance: variance });
           }
         }
       }
+
       var ts = _now();
-      await query(
+      // ATOMIC CLAIM — advance the audit out of open/in_progress in a
+      // single statement BEFORE any shelf moves. On the D1 bridge there
+      // are no interactive transactions, so this UPDATE is the
+      // serialization point: two concurrent finalizeAudit calls both
+      // reach here, but only one matches a row. The loser changes zero
+      // rows, applies NOTHING, and returns the deterministic totals — so
+      // a shelf can never be double-adjusted by overlapping finalizes.
+      // The flip also freezes the scan lines (recordScanLine / markRecount
+      // refuse on a finalized audit), so the variances we're about to
+      // apply can't shift underfoot.
+      var claim = await query(
         "UPDATE inventory_audits SET status = 'finalized', variance_count = ?1, " +
-        "variance_value_minor = ?2, finalized_at = ?3, updated_at = ?3 WHERE id = ?4",
+        "variance_value_minor = ?2, finalized_at = ?3, updated_at = ?3 " +
+        "WHERE id = ?4 AND status IN ('open', 'in_progress')",
         [varianceCount, varianceValueMinor, ts, auditId],
       );
+      if (Number(claim.rowCount || 0) !== 1) {
+        // Lost the claim — a concurrent (or prior) finalize already
+        // advanced this audit and owns the adjustment writes. Touch no
+        // shelves; return the totals computed from the now-frozen lines.
+        return {
+          variance_count:       varianceCount,
+          variance_value_minor: varianceValueMinor,
+          adjustments_written:  adjustable.length,
+        };
+      }
+
+      // PASS 2 (winner only) — apply each shelf adjustment, reconciling
+      // against what already landed under this audit's reason. The audit's
+      // slug is unique and (audit_id, sku, location_code) is UNIQUE, so
+      // every inventory_adjustments row under (sku, location_code, reason)
+      // belongs to this one logical adjustment; their summed delta is what
+      // the shelf has already moved. Applying only `variance - applied`
+      // makes a retry land exactly the remaining delta and never a double,
+      // and self-corrects if a recount changed the variance before the
+      // retry. The common abort is a respect_holds floor refusal on a
+      // negative variance; the catch re-opens the audit so the operator
+      // can clear the blocker and retry.
+      var adjustmentsWritten = 0;
+      var adjReason = "inventory-audit:" + header.slug;
+      try {
+        for (var j = 0; j < adjustable.length; j += 1) {
+          var adj = adjustable[j];
+          var appliedRow = await query(
+            "SELECT COALESCE(SUM(delta), 0) AS applied FROM inventory_adjustments " +
+            "WHERE sku = ?1 AND location_code = ?2 AND reason = ?3",
+            [adj.sku, adj.location_code, adjReason],
+          );
+          var alreadyApplied = Number((appliedRow.rows[0] || {}).applied || 0);
+          var needed = adj.variance - alreadyApplied;
+          if (needed !== 0) {
+            await inventoryLocations.adjustStock({
+              sku:           adj.sku,
+              location_code: adj.location_code,
+              delta:         needed,
+              reason:        adjReason,
+              // A negative variance shrinks the shelf — guard it from
+              // dropping below the outstanding paid holds for the SKU so a
+              // later commitHold can't be stranded. Positive variances
+              // (credits) ignore the flag.
+              respect_holds: true,
+            });
+          }
+          adjustmentsWritten += 1;
+        }
+      } catch (applyErr) {
+        // Re-open the audit so the operator can clear the blocker and
+        // retry. The reconciling apply above guarantees the retry lands
+        // only the remaining delta, so nothing double-counts.
+        await query(
+          "UPDATE inventory_audits SET status = 'in_progress', finalized_at = NULL, " +
+          "updated_at = ?1 WHERE id = ?2 AND status = 'finalized'",
+          [_now(), auditId],
+        );
+        throw applyErr;
+      }
+
       return {
         variance_count:       varianceCount,
         variance_value_minor: varianceValueMinor,

package/lib/storefront.js

@@ -19684,7 +19684,9 @@ function mount(router, deps) {
       // The customer's own ticket list, scoped to their session customer_id.
       router.get("/account/support", async function (req, res) {
         var auth = await _supportAuth(req, res); if (!auth) return;
-        var tickets = await support.listByCustomerId(auth.customer_id, { limit: 100 });
+        // First page only — the account list shows the customer's most
+        // recent tickets; listByCustomerId now returns { rows, next_cursor }.
+        var tickets = (await support.listByCustomerId(auth.customer_id, { limit: 100 })).rows;
         var cartCount = await _cartCountForReq(req);
         var url = req.url ? new URL(req.url, "http://localhost") : null;
         _send(res, 200, renderSupportList({

package/lib/support-tickets.js

@@ -821,11 +821,17 @@ function create(opts) {
     // storefront, which holds only the session customer id (the raw
     // email is never on disk), can list + ownership-gate a signed-in
     // shopper's tickets without re-deriving the email hash. Composes the
-    // same id / status / limit validators as the rest of the surface.
+    // same id / status / limit validators as the rest of the surface, and
+    // (like listForCustomer) returns `{ rows, next_cursor }` on the
+    // (opened_at DESC, id DESC) tuple so a caller that needs the customer's
+    // COMPLETE ticket set — e.g. the subject-access export, which keys on
+    // customer_id and has no email to drive listForCustomer — can page to
+    // the end instead of stopping at the first `limit`.
     listByCustomerId: async function (customerId, listOpts) {
       customerId = _uuid(customerId, "customer_id");
       listOpts = listOpts || {};
       var limit = _limit(listOpts.limit);
+      var cursorVals = _decodeCursor(listOpts.cursor, "listByCustomerId");
       var where  = ["customer_id = ?1"];
       var params = [customerId];
       var idx    = 2;
@@ -834,11 +840,20 @@ function create(opts) {
         params.push(_status(listOpts.status_filter, "status_filter"));
         idx += 1;
       }
+      if (cursorVals) {
+        where.push(
+          "(opened_at < ?" + idx + " OR " +
+          "(opened_at = ?" + idx + " AND id < ?" + (idx + 1) + "))"
+        );
+        params.push(cursorVals[0], cursorVals[1]);
+        idx += 2;
+      }
       params.push(limit);
       var sql = "SELECT * FROM support_tickets WHERE " + where.join(" AND ") +
                 " ORDER BY opened_at DESC, id DESC LIMIT ?" + idx;
       var r = await query(sql, params);
-      return r.rows.map(_hydrate);
+      var rows = r.rows.map(_hydrate);
+      return { rows: rows, next_cursor: _encodeNext(rows, limit) };
     },
 
     // Operator queue across every assignment state — newest-stale first

package/package.json

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