backend-manager 5.2.7 → 5.2.8

package/CHANGELOG.md

@@ -14,6 +14,12 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
 - `Fixed` for any bug fixes.
 - `Security` in case of vulnerabilities.
 
+# [5.2.8] - 2026-05-25
+
+### Changed
+
+- **`/user/signup` precedence flip for `activity.client`.** `routes/user/signup/post.js` now spreads `assistant.request.client` FIRST and `settings.context.client` (the browser's `getContext()` payload) LAST, so the browser-supplied values win for the `client` block. `activity.client.language` is now `navigator.language` (e.g. `en-US`) instead of the raw `Accept-Language` header list (e.g. `en-US,en;q=0.9,fr;q=0.8`); falls back to the header when no browser context was sent (bots, non-browser clients). `activity.geolocation` precedence is unchanged — Cloudflare headers (`cf-ipcountry`, etc.) still win, since the browser doesn't know its own geo. Final shape mirrors `assistant.request`: geolocation is header-authoritative, client is browser-authoritative.
+
 # [5.2.7] - 2026-05-24
 
 ### Fixed

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "backend-manager",
-  "version": "5.2.7",
+  "version": "5.2.8",
   "description": "Quick tools for developing Firebase functions",
   "main": "src/manager/index.js",
   "bin": {

package/src/manager/libraries/email/data/disposable-domains.json

@@ -417,6 +417,7 @@
   "amberwe.us",
   "ambiancewe.us",
   "ambitiouswe.us",
+  "ameady.com",
   "amelabs.com",
   "americanawe.us",
   "americancivichub.com",
@@ -656,6 +657,7 @@
   "bipochub.com",
   "bitmah.com",
   "bitmens.com",
+  "bittnex.com",
   "bitwhites.top",
   "bitymails.us",
   "biz.st",
@@ -1914,6 +1916,7 @@
   "gddp2018.edu.vn",
   "gdmail.top",
   "gdqoe.net",
+  "gebrauchtwarencenter.com",
   "gedmail.win",
   "geekforex.com",
   "geew.ru",
@@ -2102,6 +2105,7 @@
   "gynzi.co.uk",
   "gynzi.es",
   "gzb.ro",
+  "gzeos.com",
   "h0tmaii.com",
   "h2beta.com",
   "h8s.org",
@@ -3506,10 +3510,12 @@
   "nowhere.org",
   "nowmymail.com",
   "nowmymail.net",
+  "noyavip.com",
   "noyp.fr.nf",
   "nproxi.com",
   "nqmo.com",
   "nrehi.com",
+  "nriza.com",
   "nrlord.com",
   "ns01.biz",
   "nsvpn.com",

package/src/manager/routes/user/signup/post.js

@@ -137,8 +137,8 @@ function buildUserRecord(assistant, settings, inferred) {
         ...assistant.request.geolocation,
       },
       client: {
-        ...(settings.context?.client || {}),
         ...assistant.request.client,
+        ...(settings.context?.client || {}),
       },
     },
     attribution: attribution || {},

package/TODO-CANCEL-EMAIL-MISSING-ORDER-ID.md

@@ -1,159 +0,0 @@
-# TODO: Cancel email missing Order # on non-trial cancels
-
-## Symptom
-
-Observed 2026-05-23 in `_test.journey-payments-cancel@somiibo.com`'s inbox:
-
-```
-Subject: Your subscription has been cancelled #
-Body:    Order #
-         Your subscription has been cancelled.
-```
-
-The `#` after both `Subject` and `Order #` is bare — `order.id` rendered as empty string.
-
-The trial-cancel sibling (`_test.journey-payments-trial-cancel@somiibo.com`) on the SAME run got the order ID correctly:
-
-```
-Subject: Your subscription has been cancelled #3794-5306-7041
-Body:    Order #3794-5306-7041
-```
-
-So this is path-specific, not a template bug.
-
-## Root cause (narrowed but not yet proven)
-
-Two cancel paths feed the same `subscription-cancelled` transition handler ([src/manager/events/firestore/payments-webhooks/transitions/subscription/subscription-cancelled.js:17](src/manager/events/firestore/payments-webhooks/transitions/subscription/subscription-cancelled.js#L17)):
-
-```js
-subject: `Your subscription has been cancelled #${order?.id || ''}`,
-```
-
-Subject + template both render `order.id`. When `order.id` is falsy it falls through to `''`.
-
-`order.id` is built in [src/manager/events/firestore/payments-webhooks/on-write.js:241-242](src/manager/events/firestore/payments-webhooks/on-write.js#L241-L242):
-
-```js
-const order = {
-  id: orderId,
-  ...
-};
-```
-
-Where `orderId` (line 118) is:
-
-```js
-orderId = library.getOrderId(resource) || passThruOrderId;
-```
-
-`library.getOrderId(resource)` reads the order ID off the processor resource's `meta_data` field. `passThruOrderId` is a PayPal-only fallback from the hosted-page `pass_thru_content`.
-
-**Working path** (`journey-payments-trial-cancel`): the trial cancel goes through the `/payments/cancel` endpoint, which already has the `orderId` from `users/{uid}.subscription.payment.orderId`. By the time Stripe/PayPal fires the cancellation webhook back, `meta_data.orderId` on the subscription resource is set, so `library.getOrderId(resource)` returns the order ID. Email shows the ID.
-
-**Broken path** (`journey-payments-cancel`): this is the webhook-driven cancel (no `/payments/cancel` endpoint call — `orderDoc.requests.cancellation` is null in the test assertions). The webhook arrives with a subscription resource whose `meta_data.orderId` is empty (or `library.getOrderId(resource)` returns null/empty string). `passThruOrderId` is null because this is Stripe, not PayPal. `orderId` ends up null. `order.id = null`. Email renders `Order #`.
-
-## What's still unknown
-
-1. **Why is `meta_data.orderId` missing on the Stripe subscription resource at cancel time?** Possibilities:
-   - The journey test never set `meta_data` on the subscription (only on the customer or the initial intent).
-   - `library.setMetaData` was called during the new-subscription transition but Stripe's subscription resource didn't persist it (Stripe quirk where `metadata` on subscription vs. customer vs. invoice diverge).
-   - The `customer.subscription.deleted` event payload doesn't include `metadata` even when it was set — this would be a Stripe-side gotcha.
-2. **Does this affect production?** Possibly — depends on whether real users' Stripe subscription resources have `meta_data.orderId` set. Worth checking one real cancelled subscription in the Stripe dashboard.
-
-## Investigation steps
-
-1. **Re-run the cancel journey with `TEST_EXTENDED_MODE=true`** and watch the BEM logs:
-   ```bash
-   cd /Users/ian/Developer/Repositories/Somiibo/somiibo-backend/functions
-   TEST_EXTENDED_MODE=true npx mgr test events/payments/journey-payments-cancel
-   ```
-   Search the logs around the cancellation webhook for the resolved `orderId` value:
-   ```bash
-   npx mgr logs:read --filter "journey-payments-cancel" --limit 200 | grep -i "orderid\|order id"
-   ```
-
-2. **Inspect the raw webhook payload** stored in `payments-webhooks/{eventId}` for that test run:
-   ```bash
-   npx mgr firestore:query "payments-webhooks" --limit 20  # find the deleted-subscription event
-   npx mgr firestore:get "payments-webhooks/<eventId>"     # inspect raw.data.object.metadata
-   ```
-   If `raw.data.object.metadata.orderId` is empty → confirms Stripe didn't include it in the event.
-
-3. **Check `library.getOrderId(resource)` implementation** for the Stripe library:
-   ```bash
-   grep -n "getOrderId" /Users/ian/Developer/Repositories/ITW-Creative-Works/backend-manager/src/manager/libraries/payment/stripe.js
-   ```
-   Confirm what field path it reads. If it reads only `resource.metadata.orderId`, that's the bug — should also check `resource.metadata.bm_orderId` (some processors have different conventions) or fall through to a Firestore lookup.
-
-## Fix options (in order of preference)
-
-### Option A — Fall back to userDoc on the transition side (safest)
-
-In [subscription-cancelled.js:17](src/manager/events/firestore/payments-webhooks/transitions/subscription/subscription-cancelled.js#L17), if `order.id` is missing, fall back to `userDoc.subscription.payment.orderId`:
-
-```js
-const orderId = order?.id || userDoc?.subscription?.payment?.orderId || '';
-
-sendOrderEmail({
-  template: 'core/order/cancelled',
-  subject: `Your subscription has been cancelled${orderId ? ` #${orderId}` : ''}`,
-  ...
-  data: {
-    order: {
-      ...order,
-      id: orderId,
-      ...
-    },
-  },
-});
-```
-
-This is the **safest** fix because it works regardless of whether the bug is in `library.getOrderId`, in Stripe's event payload, or in how `meta_data` was set originally. `userDoc.subscription.payment.orderId` is written when the subscription first activates and reliably has the ID by cancel time.
-
-The subject also degrades gracefully — `Your subscription has been cancelled` (no bare `#`) when the ID truly can't be found.
-
-### Option B — Fix at the source (`on-write.js`)
-
-In [on-write.js:118](src/manager/events/firestore/payments-webhooks/on-write.js#L118), add another fallback after `library.getOrderId`:
-
-```js
-orderId = library.getOrderId(resource)
-  || passThruOrderId
-  || userDoc?.subscription?.payment?.orderId
-  || null;
-```
-
-This fixes it for ALL handlers (not just cancel), and at the cost of a Firestore read of the user doc earlier in `on-write.js` than today. May not need a new read if userDoc is already fetched by this point — confirm by reading the function top-to-bottom.
-
-### Option C — Fix `library.getOrderId(resource)` (Stripe library)
-
-If investigation step 3 shows the Stripe library is reading the wrong field path, fix it there. Smallest blast radius if the bug is genuinely in one processor's resolver and not a Stripe-event-payload gotcha.
-
-## Recommendation
-
-Do **A + B together** — A makes the email correct today regardless of root cause; B prevents the same gap from biting any other handler (refund, suspend, etc.). C only if investigation step 3 reveals an actual mis-read.
-
-## Regression test
-
-Add an assertion to `test/events/payments/journey-payments-cancel.js` that the post-cancellation userDoc still has `subscription.payment.orderId` set AND that the cancel email's `order.id` would render non-empty. Without a regression test, the same bug will silently come back the next time someone refactors `library.getOrderId`.
-
-Pseudo-assertion:
-
-```js
-assert.ok(userDoc.subscription?.payment?.orderId, 'userDoc.subscription.payment.orderId should be set after cancellation');
-// And if we capture the email payload (via a test-mode hook in sendOrderEmail), assert order.id !== '' in the rendered data.
-```
-
-If `sendOrderEmail` doesn't already have a test-mode capture, that's a small enhancement worth doing once — it would let every email-emitting transition assert its rendered payload, not just cancel.
-
-## Affected versions
-
-Confirmed broken: BEM 5.2.5 (current live on Somiibo as of 2026-05-23). Likely broken in earlier versions too — the `order?.id || ''` template defensive fallback was added explicitly to handle missing IDs, suggesting this gap has been latent for a while. The trial-cancel path masked it because trial cancels go through the endpoint and have `orderId` set in a different code path.
-
-## Related files
-
-- [src/manager/events/firestore/payments-webhooks/transitions/subscription/subscription-cancelled.js](src/manager/events/firestore/payments-webhooks/transitions/subscription/subscription-cancelled.js) — handler with `order?.id || ''` fallback
-- [src/manager/events/firestore/payments-webhooks/on-write.js:241](src/manager/events/firestore/payments-webhooks/on-write.js#L241) — `order` object construction
-- [src/manager/events/firestore/payments-webhooks/on-write.js:118](src/manager/events/firestore/payments-webhooks/on-write.js#L118) — `orderId` resolution from `library.getOrderId` + pass-through fallback
-- [test/events/payments/journey-payments-cancel.js](test/events/payments/journey-payments-cancel.js) — broken-path test (currently passes because it doesn't assert the email payload)
-- [test/events/payments/journey-payments-trial-cancel.js](test/events/payments/journey-payments-trial-cancel.js) — working-path test