backend-manager 5.2.6 → 5.2.8

package/CHANGELOG.md

@@ -14,6 +14,18 @@ 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
+
+- **`inferContact` silent-failure logging.** When the AI inference returned an empty result (either the AI call failed and returned null, or `gpt-5-mini` returned a parsed response with all-empty fields, or the response shape was missing `firstName`), the whole flow silently swallowed the failure and the signup's `user.personal.name` got written as `null`/`null`. Confirmed live on Somiibo: signed up `ian.wiedenman.business@gmail.com` twice on the same backend — first signup inferred nothing (empty name written), second signup correctly inferred "Ian Wiedenman". Same email, same code, transient AI hiccup, zero log trail. Added three unconditional diagnostic logs to `src/manager/libraries/infer-contact.js` (AI returned null, AI parsed response had all fields empty, AI response missing firstName) plus a log in `src/manager/routes/user/signup/post.js#inferUserContact` when the helper returns null. Next silent failure will at least leave a breadcrumb.
+
 # [5.2.6] - 2026-05-24
 
 ### Added

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "backend-manager",
-  "version": "5.2.6",
+  "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/libraries/infer-contact.js

@@ -26,6 +26,9 @@ async function inferContact(email, assistant) {
     if (aiResult) {
       return aiResult;
     }
+    assistant.log(`inferContact: AI returned null for ${email} — falling back to empty result`);
+  } else {
+    assistant.log(`inferContact: BACKEND_MANAGER_OPENAI_API_KEY not set — skipping AI inference for ${email}`);
   }
 
   return { firstName: '', lastName: '', company: '', confidence: 0, method: 'none' };
@@ -57,18 +60,22 @@ async function inferContactWithAI(email, assistant) {
 
     const parsed = result?.content;
     if (parsed?.firstName !== undefined) {
-      return {
+      const inferred = {
         firstName: capitalize(parsed.firstName || ''),
         lastName: capitalize(parsed.lastName || ''),
         company: capitalize(parsed.company || ''),
         confidence: typeof parsed.confidence === 'number' ? parsed.confidence : 0.5,
         method: 'ai',
       };
+      if (!inferred.firstName && !inferred.lastName && !inferred.company) {
+        assistant.log(`inferContactWithAI: AI parsed response had ALL fields empty for ${email}. Raw:`, parsed);
+      }
+      return inferred;
     }
+
+    assistant.log(`inferContactWithAI: AI response missing firstName for ${email}. Raw result:`, result);
   } catch (e) {
-    if (assistant) {
-      assistant.error('inferContactWithAI: Failed:', e);
-    }
+    assistant.error('inferContactWithAI: Failed:', e);
   }
 
   return null;

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 || {},
@@ -229,6 +229,7 @@ async function inferUserContact(assistant, email) {
     const inferred = await inferContact(email, assistant);
 
     if (!inferred?.firstName && !inferred?.lastName && !inferred?.company) {
+      assistant.log(`signup(): inferUserContact returned empty result for ${email} (method=${inferred?.method || 'unknown'})`);
       return null;
     }
 

package/test/routes/test/usage.js

@@ -239,6 +239,10 @@ module.exports = {
     // Test 9: Cron resets daily counters for authenticated users
     {
       name: 'cron-resets-daily-counters',
+      // bm_cronDaily runs all daily jobs serially; reset-usage is at the end of
+      // the alphabetical sequence. In EXTENDED mode the real-API jobs ahead of
+      // it can take ~50s combined — override the suite's 30s default.
+      timeout: 75000,
       async run({ assert, firestore, state, accounts, waitFor, pubsub }) {
         // Verify daily counter is > 0 before cron
         const beforeDoc = await firestore.get(`users/${accounts.basic.uid}`);
@@ -251,19 +255,24 @@ module.exports = {
         // Trigger cron via PubSub
         await pubsub.trigger('bm_cronDaily');
 
-        // Wait for cron to reset daily counter
+        // Wait for cron to reset daily counter.
+        // bm_cronDaily executes every registered daily job sequentially. In EXTENDED
+        // mode the real-API jobs (marketing-newsletter-generate, expire-paypal-cancellations,
+        // ghostii-auto-publisher, etc.) can take 40-50s combined before reset-usage
+        // (alphabetical tail) gets its turn. 70s gives that the headroom it needs;
+        // the per-test `timeout` below matches.
         try {
           await waitFor(
             async () => {
               const doc = await firestore.get(`users/${accounts.basic.uid}`);
               return doc?.usage?.requests?.daily === 0;
             },
-            15000,
+            70000,
             500
           );
           assert.ok(true, 'Daily counter was reset to 0 by cron');
         } catch (error) {
-          assert.fail('Daily counter should be reset to 0 within 15s');
+          assert.fail('Daily counter should be reset to 0 within 70s');
         }
       },
     },

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