Fix /team/sales staging outage: batch the Customer 360 per-customer query fan-out (~4,000 → ~35 D1 calls)

[PawSpaceIND]

The outage

Staging /team/sales renders "Too many API requests by single Worker invocation" and an empty customer list (screenshot from UAT). Root cause, lib/customer-360.ts:7:

• buildCustomer360() looped every customer (up to 500) and ran 8 D1 queries per customer (addresses, pets, bookings, food orders, coupons, cases, tickets, preferences) → ~4,000 subrequests in a single GET, far past Cloudflare's per-invocation cap.
• Both APIs the page calls die on real data: /api/customer-360 directly, and /api/revenue-intelligence whose refresh() also builds the full 360 on every GET. Result: the whole Sales worklist showed nothing.

The fix

Batched section reads: one query per table per chunk of 80 customer IDs (respecting D1's ~100 bound-parameter ceiling), grouped in JS.

• 300 customers: ~2,402 D1 calls → ~35. 500 customers through the real route end-to-end: < 70, comfortably inside the cap.
• The old per-row ORDER BY/LIMIT semantics are reproduced exactly in JS — default address first, newest bookings first with the 100/50-per-customer caps, food-order → pet_food timeline merge, consent defaults, LTV exclusions, shared-phone/email dedup — so the output shape is byte-identical.
• Every existing consumer benefits automatically and passes unchanged: revenue-crm, revenue-intelligence, promotion & marketing governance, daily revenue opportunities, AI conversation context, customer business view.
• Missing section tables still degrade to empty sections (guarded reads), never a crash.

Tests

tests/customer-360-fanout.test.mjs — 4 real-execution tests with a query-counting D1 shim (batches counted as one request, mirroring D1), so the fix is pinned by an actual budget rather than inspection:

• 300 customers build under a 50-call budget (pre-fix: ~2,402) with all 300 records returned.
• The real /api/customer-360 route with 500 customers stays under 70 calls end to end and returns all 500.
• Field-by-field semantics: address ordering (default first), merged booking timeline newest-first, Adult Dog Food × 2 package label, LTV excludes cancelled, consent flags, open-ticket count, duplicate-candidate detection, and the per-customer LIMIT 50 on coupons (120 stored → newest 50 returned).
• Cold-DB build with no section tables at all.

Full suite: all pre-existing customer-360 consumers (CRM stack, revenue stack, food hardening, AI intelligence, daily-revenue governance tests) pass against the batched rebuild — behavioral equivalence verified by the tests that already pinned those behaviors.

Files changed

• lib/customer-360.ts — batched fetchGrouped reads replacing the per-customer loop queries
• tests/customer-360-fanout.test.mjs — new (4 tests)

Gates

• npm run typecheck — 0 errors
• npm run lint — 0 errors, 14 warnings (all pre-existing baseline, none new)
• npm test — 1192/1192 pass (1188 existing + 4 new)

After merge + deploy, /team/sales on staging should load its worklist normally.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CE4fKzrWRZetcYKh8CaU3b

---

Generated by Claude Code

[PawSpaceIND]

Closing — superseded, and the useful half is already on main.

• The fix landed as Kill the Customer 360 N+1 that was blocking every marketing campaign #160, corrected to a chunk of 80 by Adopt the call-budget guard from #152, and fix the under-chunked read it caught #166. lib/customer-360.ts on main no longer issues 8 queries per customer.
• The test landed too: tests/customer-360-fanout.test.mjs on main is byte-identical to this branch's. Nothing here is unmerged coverage.

Diffing this branch against current main leaves only the older implementation of the same fix, so there is nothing left to merge.

One thing carried forward in #158 rather than lost: main briefly held two chunk sizes in two modules — 80 in lib/customer-360.ts and 50 in lib/unit-economics.ts (#165). Both now go through one helper at one size, with a test that fails if a module declares its own again.

Thanks to #166 for porting the budget test — the point it makes is the right one: a bind-parameter cap catches one statement that is too wide, but only a call count catches many statements that are each individually fine.

---

Generated by Claude Code

[PawSpaceIND]

Closing this — the fix is superseded, but the test was taken and it caught a defect in the version that shipped.

#160 fixed the same buildCustomer360 N+1 (8 queries per customer × up to 1,000 customers, ~8,000 subrequests against Cloudflare's 1,000 ceiling) and merged first, so lib/customer-360.ts here is redundant.

tests/customer-360-fanout.test.mjs was not redundant. It is now on main via #166, and porting it immediately failed:

	300 customers	500 customers	Budget asserted here
chunk 50 — what #160 shipped	51 calls	82 calls	≤ 50 / ≤ 70 → failed both
chunk 80 — what this PR used	34 calls	58 calls	passed

#160 removed the fan-out but sized the chunk a third too small. ID_CHUNK is now 80 on main, verified by reverting to 50 and watching this test fail with got 51 D1 calls.

Two other things from this PR that #160 lacked and now has:

• The call-budget shim. The repo already enforced D1's bind-parameter cap, which would never have caught either defect — 8 narrow queries per customer are each perfectly legal. Only counting calls catches a fan-out. Both guards now live in tests/helpers/d1-harness.mjs, with batch() charged as one subrequest as real D1 charges it, and a floor asserted alongside every ceiling so a budget cannot pass on work that silently did nothing.
• The behavioural proof. Kill the Customer 360 N+1 that was blocking every marketing campaign #160 claimed byte-identical output after the refactor and had no test for it. This PR's field-by-field assertions — default-address-first ordering, newest-first booking timeline, per-customer LIMIT 50 on coupons, food-order merge, consent defaults, duplicate detection — are what actually establish that.

Credit for the framing: assert the property that would actually break, not the shape of the code. That is now the shared harness guard, and the bind-cap check that had been stranded in a single suite was folded into it.

Nothing further needed here.

---

Generated by Claude Code