@blamejs/blamejs-shop 0.4.102 → 0.4.103

package/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- v0.4.103 (2026-06-25) — **A return refund that exceeds the order's remaining refundable balance is now refused cleanly, instead of failing at the payment provider.** The direct refund console refuses an over-refund up front: it compares the requested amount against the order's remaining refundable balance and returns a clear 'more than is still refundable' error before any money moves. The provider-backed return (RMA) refund path skipped that check — it issued the RMA's approved amount straight to the payment provider, relying on the provider to reject anything past the captured charge. The result was a late, opaque provider-failure error (and a returns workflow left mid-flight) instead of the clean, actionable refusal the console gives. The RMA refund path now applies the same remaining-balance guard before calling the provider: an approved amount greater than what remains refundable — including a return stacked on top of an earlier partial refund — is refused with the same clear message, the return is left in its received state so the operator can re-approve a corrected amount, and the payment provider is never dialed. A refund of an already-refunded return continues to return the existing conflict response. No configuration changes. **Fixed:** *Return (RMA) refunds honor the order's remaining-balance cap before reaching the payment provider* — A provider-backed return refund issued the return's approved amount directly to Stripe or PayPal with no remaining-balance check, so an amount larger than what was still refundable on the order — for example a return approved for more than the order total, or stacked on top of an earlier partial refund — failed only at the payment provider, surfacing as an opaque provider-failure error rather than the clean refusal the direct refund console returns. The return refund path now compares the approved amount against the order's remaining refundable balance first: an over-cap amount is refused with a clear message, the return stays in its received state so a corrected amount can be re-approved, and the provider is never called. A refund attempt on an already-refunded return still returns the existing conflict response.
+
 - v0.4.102 (2026-06-25) — **Vendored framework refreshed to 0.15.26.** Updates the vendored blamejs framework to 0.15.26. The substantive upstream change is a worker-thread handle leak fix in the sandbox primitive: b.sandbox.run now awaits the worker's termination before resolving, so repeatedly running sandboxed code in a long-lived process no longer accumulates leaked MessagePort handles that keep the event loop alive and slow graceful shutdown. The follow-up 0.15.26 build is upstream test-harness correctness only and ships a library byte-for-byte identical to 0.15.25. No runtime API changes and no behavior change for this storefront, which does not run untrusted code through the sandbox primitive; no operator action required. **Changed:** *Vendored framework refreshed to 0.15.26* — Refreshes the vendored blamejs framework to 0.15.26. Upstream 0.15.25 fixes a worker-thread MessagePort leak in the sandbox primitive (b.sandbox.run now waits for the worker to terminate before resolving), and 0.15.26 is a test-harness-only build whose shipped library is identical to 0.15.25. There are no runtime API changes; this storefront does not expose the sandbox primitive on any request path, so there is no operator-visible behavior change and no action required.
 
 - v0.4.101 (2026-06-25) — **Bulk cart operations now use the same per-line quantity ceiling as a normal add-to-cart, so a large line is no longer un-bulk-addable or silently reduced.** The cart enforces a per-line quantity ceiling on every add-to-cart. The bulk-operations surface (bulk add and reorder) carried its own copy of that ceiling that had drifted ten times lower than the cart's. The mismatch meant a line legitimately built up to the cart's ceiling through normal add-to-cart could not be added to in bulk (the whole bulk batch was rejected), and a reorder of such a line silently clamped its quantity down instead of preserving it. Bulk operations now source the ceiling directly from the cart primitive, so the two always agree: the same quantity that add-to-cart accepts is accepted in bulk, and a reorder no longer quietly reduces a line. No configuration changes. **Fixed:** *Bulk add and reorder share the cart's per-line quantity ceiling* — Bulk cart operations validated and clamped line quantities against their own ceiling, which was ten times lower than the one the cart applies on a normal add-to-cart. As a result a line whose quantity was legitimately built up to the cart's ceiling could not be bulk-added to — the entire batch was refused — and a reorder of that line silently clamped its quantity down rather than keeping it. The bulk surface now reads the ceiling from the cart primitive itself, so bulk add accepts exactly what add-to-cart accepts and a reorder preserves a line's quantity instead of reducing it.

package/lib/admin.js

@@ -4784,6 +4784,12 @@ function mount(router, deps) {
       if (!e) return null;
       if (e.code === "RMA_NOT_FOUND") return { status: 404, slug: "return-not-found" };
       if (e.code === "RMA_TRANSITION_REFUSED") return { status: 409, slug: "return-transition-refused" };
+      // A refund-cap refusal raised by the provider-refund pre-check (the same
+      // over-refund / nothing-remaining guards the direct console maps to 422)
+      // is the operator's problem — a clean 422, not a 502 provider failure.
+      if (e._refundCode === "over-refund" || e._refundCode === "nothing-remaining") {
+        return { status: 422, slug: e._refundCode };
+      }
       return null;
     }
 
@@ -5173,11 +5179,55 @@ function mount(router, deps) {
       // stamped at claim time is the operator's own text when supplied, else
       // a stable marker; the live provider refund id is on the audit row +
       // the JSON response, so it stays reconcilable without a second write.
+      // Claiming first also keeps an already-refunded RMA a clean 409
+      // (the atomic claim refuses it) rather than masking it behind the
+      // amount guard below.
       var claimed = await returns.refund(rma.id, {
         operator_notes: (body.operator_notes && body.operator_notes.length)
           ? body.operator_notes
           : "provider refund issued",
       });
+
+      // Over-refund guard — claim succeeded, but the approved amount must
+      // still fit the order's remaining refundable balance. Mirror the
+      // direct console's over-refund cap BEFORE the provider is dialed, so
+      // an RMA refund_amount_minor that exceeds what remains (already fully
+      // refunded, or stacked past the order total via a prior console/RMA
+      // refund) is refused cleanly (422) instead of failing late at the PSP
+      // as a 502. recordPartialRefund (below) folds each RMA refund into
+      // refundedTotalMinor, so `remaining` reflects prior console AND RMA
+      // refunds alike. On refusal the just-taken claim is RELEASED (back to
+      // received, retryable with a corrected amount) so the RMA never
+      // strands in `refunded` with no money moved. An unset
+      // refund_amount_minor means "refund what remains" — the provider caps
+      // it at the capturable balance, so it proceeds unless nothing remains.
+      // The whole guard runs inside a try/catch that RELEASES the claim on
+      // ANY throw — whether the deliberate over-cap refusal below OR a
+      // transient failure of the balance read itself. Without that, a
+      // refundedTotalMinor read that rejects after the claim moved the RMA to
+      // `refunded` would exit before the provider-call release path, stranding
+      // the RMA behind a 409 with no money moved.
+      try {
+        var rmaAlreadyMinor   = await order.refundedTotalMinor(order2.id);
+        var rmaRemainingMinor = (Number(order2.grand_total_minor) || 0) - rmaAlreadyMinor;
+        if (rmaRemainingMinor <= 0 ||
+            (rma.refund_amount_minor != null && rma.refund_amount_minor > rmaRemainingMinor)) {
+          var capErr = (rmaRemainingMinor <= 0)
+            ? new TypeError("This order is already fully refunded — nothing remains to refund.")
+            : new TypeError("That RMA refund of " + pricing.format(rma.refund_amount_minor, order2.currency) +
+                            " is more than the " + pricing.format(rmaRemainingMinor, order2.currency) +
+                            " still refundable on this order.");
+          capErr._refundCode = (rmaRemainingMinor <= 0) ? "nothing-remaining" : "over-refund";
+          throw capErr;
+        }
+      } catch (guardErr) {
+        // Release the just-taken claim (back to received, retryable) so
+        // neither the over-cap refusal nor a transient read failure leaves
+        // the RMA stranded in `refunded`. No money has moved yet.
+        try { await returns.releaseRefundClaim(rma.id); }
+        catch (_relErr) { /* drop-silent — guardErr below is the actionable one */ }
+        throw guardErr;
+      }
       var idem = "rma-refund:" + rma.id;
       var refund;
       var providerRefund;

package/lib/asset-manifest.json

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

package/package.json

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