@blamejs/blamejs-shop 0.4.37 → 0.4.38

package/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- v0.4.38 (2026-06-14) — **Close two refund-path money-creation defects: loyalty restoration over-minting across refund passes, and a double-submitted partial refund phantom-crediting gift card and loyalty.** Two confirmed money-creation bugs in the refund path, both surfaced by an adversarial review of the recent cash-first refund accounting. First, restoring redeemed loyalty points could mint more than the customer spent when an order was refunded across more than one pass (a partial slice then the terminal refund): the restore scan re-read the positive reversal rows it writes as if they were fresh redemptions and credited them again, compounding past the original spend. Second, a console partial-refund double-submit — a double-click, a retry, or a refund webhook arriving after a console refund — appended the refund ledger twice under the same payment-provider refund id; the provider moved the money once, but the duplicate ledger row double-counted the refunded total, which drove the cash-first accounting to re-credit gift-card and loyalty value the customer was never actually refunded. Both are fixed and covered by regression tests. No migration to apply. **Fixed:** *Loyalty restoration no longer over-mints across multiple refund passes* — When a refund runs in more than one pass — a partial cash refund followed by a terminal full refund — restoring redeemed points scanned every loyalty row tied to the order, including the positive reversal rows the restore itself writes (which share the same transaction type as a redemption). A later pass re-read a prior pass's reversal as a fresh redemption and credited it again, so the restored points exceeded the original spend. The scan now reads only the genuine burns, so the cumulative restored points converge exactly on the redeemed amount regardless of how many passes run. · *A double-submitted partial refund no longer phantom-credits gift card and loyalty* — Recording a partial refund now dedupes on the payment-provider refund id in a single conditional write, so the existence check and the ledger append are one atomic statement — two concurrent submits of the same refund (a double-click, a retry, or a refund webhook racing the console) can no longer both record. The Stripe refund webhook now stamps that same refund id alongside the cash share it mirrors, so a refund the webhook records before the console write is recognized and the console write becomes a no-op. Previously a duplicate row double-counted the order's refunded total, which on a split-tender order pushed the cumulative past the cash captured and re-credited the full gift-card and loyalty value the customer was never refunded.
+
 - v0.4.37 (2026-06-13) — **Restore the production container — accept the node-owned tmpDir on Cloudflare Containers — and adopt blamejs 0.15.9 on Node 24.16.** The deploy-recovery release that fixes the container startup crash-loop at its root, and moves the framework forward. blamejs 0.15.0 made db.init fail-closed when the encrypted-at-rest working-copy tmpDir is not a recognized tmpfs mount (/dev/shm, /run/shm, /run/user, /tmp), so the decrypted copy can't leak to a persistent disk. The container sets BLAMEJS_TMPDIR=/app/tmp — a node-owned persistent path, used because Cloudflare's Firecracker runtime does not grant the non-root node user write access to /dev/shm — so every 0.15.x boot threw db/tmpdir-not-tmpfs and the container crash-looped, while edge-served pages stayed up. The container's filesystem is ephemeral (destroyed on stop, never snapshotted or replicated), so the disk-residency the guard protects against does not exist here; this release passes the documented opt-out (the db.allowNonTmpfsTmpDir flag on createApp) rather than weakening encryption-at-rest. With the container booting again, the release also adopts the latest blamejs 0.15.9 — SQLite parse-time resource caps on the raw-SQL surface, an atomic-rename retry that rides out transient file locks, and a one-call secure logout that emits Clear-Site-Data — and raises the Node floor to 24.16, the version 0.15.9 requires (the runtime was never implicated in the outage). Account, cart, checkout, and admin respond again. No migration to apply. **Changed:** *Vendored blamejs advanced to 0.15.9; Node floor raised to 24.16* — The vendored framework moves to 0.15.9 — node:sqlite handles construct with SQLITE_LIMIT_* caps (a 1 MiB statement parse-time cap and ATTACH denied on the raw-SQL surface), every final temp-to-destination rename retries through a transient file lock, and b.session.logout destroys a session and emits an RFC 9527 Clear-Site-Data header in one call. 0.15.9's engines floor is Node 24.16, so the package engines, the container base image, .nvmrc, and CI all move to 24.16; the runtime change is independent of and was not the cause of the startup issue fixed above. **Fixed:** *Container boots on Cloudflare Containers under blamejs 0.15.x* — The application now passes the documented db.allowNonTmpfsTmpDir opt-out to createApp, so the encrypted-at-rest tmpDir check accepts the node-owned /app/tmp path the container is forced to use on Cloudflare's Firecracker runtime (where the non-root node user cannot write /dev/shm). Encryption-at-rest stays on; the opt-out is sound because the container filesystem is ephemeral and is never snapshotted or replicated. Without it, blamejs 0.15.0+ fail-closes db.init at boot and the container crash-loops — which is what took account, cart, checkout, and admin offline. Operators running the container on a platform without a writable tmpfs for the app user need this flag; operators with a real tmpfs should point BLAMEJS_TMPDIR at it instead.
 
 - v0.4.36 (2026-06-13) — **Pin vendored blamejs to 0.15.6 — the production container crash-loops on 0.15.7 and 0.15.8.** A deploy-recovery release that pins the vendored framework to the last version the production container booted on. The prior release attributed the container startup crash-loop to the Node minimum, but the container stayed down on Node 24.14.1 with vendored blamejs 0.15.8 — isolating the cause to the vendored framework: blamejs 0.15.7 and 0.15.8 crash-loop the deployed container's live cluster + database-bridge startup (the process exits cleanly during boot instead of staying up and listening, so the health check fails and it restarts in a loop). The in-image build smoke runs the test suite, not the production server boot, so it passes on every version and cannot catch this. This release pins the vendored blamejs back to 0.15.6 — the last version the container booted and served on — restoring account, cart, checkout, and admin. The Node minimum stays 24.14.1; it is not implicated (the container failed on 0.15.8 with 24.14.1 too). Re-adopting blamejs 0.15.7 or later is held until the startup regression is fixed. No migration to apply. **Fixed:** *Production container boots and serves again on vendored blamejs 0.15.6* — The vendored framework is pinned back to 0.15.6, the last version the deployed container completed startup on, so account, cart, checkout, and admin respond again. blamejs 0.15.7 and 0.15.8 left the container exiting during the live cluster + database-bridge boot — a path the in-image build smoke (which runs the test suite, not the production server boot) does not exercise — so they passed every build gate yet failed to stay up once deployed. The vendored tree is pinned through the vendor pipeline with integrity hashes re-stamped.

package/lib/asset-manifest.json

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

package/lib/checkout.js

@@ -427,6 +427,14 @@ function create(deps) {
     var remaining = grand - refundedSoFar;
     var delta     = cumulative - refundedSoFar;
     var meta = { stripe_event_id: event.id };
+    // Stamp the provider refund id (the charge carries its refunds newest-
+    // first) so a console refund recorded AFTER this webhook dedupes against
+    // it — recordPartialRefund keys idempotency on the refund id, and without
+    // it a webhook-first refund and the console write would both land,
+    // double-counting the refunded total on a split-tender order.
+    var _stripeRefundId = charge && charge.refunds && Array.isArray(charge.refunds.data) &&
+      charge.refunds.data[0] && charge.refunds.data[0].id;
+    if (_stripeRefundId) { meta.stripe_refund_id = _stripeRefundId; }
     if (charge.refunded === true || cumulative >= grand) {
       // Charge fully refunded — terminal edge. (On a split-tender order the
       // charge covers only the provider-paid share; a full charge refund

package/lib/loyalty.js

@@ -441,9 +441,16 @@ function create(opts) {
       }
       var effRefunded = refundedMinor > orderTotalMinor ? orderTotalMinor : refundedMinor;
 
+      // Scan only the GENUINE burns (source = 'redeem'), never the positive
+      // 'redeem-reversal' rows this function writes below — those also carry
+      // transaction_type 'redeem', so without the source filter a second
+      // restore pass (the cash-first refund path runs this once for the
+      // partial slice and again on the terminal refund edge) would re-read a
+      // prior pass's reversal as a fresh redemption and credit it again,
+      // compounding the restore past the original spend (money creation).
       var rows = (await query(
         "SELECT id, customer_id, points, restored_points FROM loyalty_transactions " +
-        "WHERE order_id = ?1 AND transaction_type = 'redeem'",
+        "WHERE order_id = ?1 AND transaction_type = 'redeem' AND source = 'redeem'",
         [oid],
       )).rows;
       var restoredTotal = 0;

package/lib/order.js

@@ -957,17 +957,45 @@ function create(opts) {
       var meta = Object.assign({}, opts2.metadata || {});
       meta.amount_minor = opts2.amount_minor;
       meta.partial = true;
+      // Idempotency by provider refund id, enforced ATOMICALLY. The provider
+      // refund id (stripe_refund_id / paypal_refund_id, stamped by the admin
+      // console's _refundLedgerMeta and by both the Stripe and PayPal webhook
+      // mirrors) is the dedupe identity — the provider moves the money once.
+      // A console double-submit, a retry, or a refund webhook racing the
+      // console write would otherwise append a SECOND 'refund' row, double-
+      // counting refundedTotalMinor and driving the cash-first block below to
+      // re-credit gift-card + loyalty value the customer was never refunded
+      // (money creation). The append is a single INSERT...SELECT...WHERE NOT
+      // EXISTS, so the existence check and the write are ONE statement: two
+      // concurrent submits of the same refund id can't both land (the second's
+      // guard sees the first's row), closing the read-then-write race a
+      // separate SELECT would leave open — with no schema change. rowCount 0
+      // means a row for this refund id was already present: this call is a
+      // replay, so record nothing and return the order unchanged (the
+      // cash-first re-credit below is skipped). Refunds with no provider id
+      // (a legacy/manual record) take the plain unconditional append.
       var ts = _now();
-      await query(
-        "INSERT INTO order_transitions (id, order_id, from_state, to_state, on_event, reason, metadata_json, occurred_at) " +
-        "VALUES (?1, ?2, ?3, ?3, 'refund', ?4, ?5, ?6)",
-        [
-          b.uuid.v7(), orderId, current.status,
-          opts2.reason || null,
-          JSON.stringify(meta),
-          ts,
-        ],
-      );
+      var _refundId = (meta.stripe_refund_id || meta.paypal_refund_id) || null;
+      if (_refundId) {
+        var _appended = await query(
+          "INSERT INTO order_transitions (id, order_id, from_state, to_state, on_event, reason, metadata_json, occurred_at) " +
+          "SELECT ?1, ?2, ?3, ?3, 'refund', ?4, ?5, ?6 " +
+          "WHERE NOT EXISTS (SELECT 1 FROM order_transitions " +
+          "WHERE order_id = ?2 AND on_event = 'refund' " +
+          "AND (json_extract(metadata_json, '$.stripe_refund_id') = ?7 " +
+          "     OR json_extract(metadata_json, '$.paypal_refund_id') = ?7))",
+          [b.uuid.v7(), orderId, current.status, opts2.reason || null, JSON.stringify(meta), ts, _refundId],
+        );
+        if (Number(_appended.rowCount || 0) === 0) {
+          return await this.get(orderId);   // replay — this refund id already recorded, no-op
+        }
+      } else {
+        await query(
+          "INSERT INTO order_transitions (id, order_id, from_state, to_state, on_event, reason, metadata_json, occurred_at) " +
+          "VALUES (?1, ?2, ?3, ?3, 'refund', ?4, ?5, ?6)",
+          [b.uuid.v7(), orderId, current.status, opts2.reason || null, JSON.stringify(meta), ts],
+        );
+      }
       // updated_at is bumped so the order surfaces at the top of the
       // operator recent-orders list after a partial refund, matching how a
       // real FSM transition touches it.

package/package.json

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