For Stakeholders

Why this matters

The Official WhatsApp integration is often a clinic's front door — it's where new leads and patients make first contact. This PR fixes a bug where that very first message could be silently dropped if it happened to arrive in a tight race with another delivery for the same contact, with no error surfaced anywhere — not to the patient, not to the clinic, not to any monitoring the team currently has (the failure path only reached console.log, no Sentry capture, no retry; see The race condition fix).

That combination — silent, unmonitored, first-contact-only — is the kind of bug that shows up as "our bot ghosted a lead" complaints rather than as an error dashboard spike, so its real-world frequency prior to this fix is unknown.

Risk and scope

• Scope of the change: one file, one function, ~90 lines touched. No schema

migration, no API contract change, no new dependency.

• Risk introduced: low. The fix only adds a catch branch for a specific,

identifiable database error code (P2002); any other error still propagates exactly as before. The main code path (no race) is unchanged.

• Risk not addressed by this PR: there is currently no automated test for

this logic (see For Quality), so regressions here would only be caught by re-discovering the same race in production or in manual/load testing.

• Known, deliberate limitation: this PR does not merge two conversation

rows that end up representing the same patient under two different addresses — that remains a separate, unscheduled piece of work, flagged directly in the code's own comments.

Bottom line

This closes a specific, low-probability-but-high-impact data-loss gap in lead intake, at low implementation risk, without expanding scope to the (harder, still-open) job of merging duplicate conversation identities.