Walkthrough

This is a backend concurrency fix inside one service function — there is no new screen, button, or setting to click through. What follows is a tour of the real screen where the effect of this bug (and this fix) shows up: the Official WhatsApp conversations inbox in clinic-web, captured live from the branch sandbox.

Where a lost message would have surfaced

Logged in as the owner demo user, the WhatsApp Bot module lives at /whatsapp, under a Conversations tab:

This sandbox has WhatsApp message delivery turned off (whatsapp: false in the sandbox config), so the list is empty here — there is no live traffic hitting the webhook to populate it. That is expected and worth calling out explicitly: this fix cannot be demonstrated by clicking around the UI. Before this PR, the bug's symptom was an absence — a customer's first WhatsApp message simply never appearing in this list, with no error shown anywhere in the product. Two messages arriving within milliseconds of each other from a brand-new contact was enough to make one of them vanish before this fix; see The race condition fix for exactly why.

Where the bot is configured

The same module's Settings tab is where a clinic connects and configures its WhatsApp Business number — unrelated to this fix, but it's the other real screen in this area of the product, shown here for orientation:

How to actually verify this fix

Because the failure only shows up under concurrent load on the webhook endpoint, verifying it means exercising the backend directly rather than the UI — see For Quality for a concrete way to reproduce the race (firing two near-simultaneous webhook payloads for the same new contact) and confirm both messages now land on one conversation instead of one disappearing.