← Back to PRs

#16608: feat(whatsapp): resolve outbound @mentions to clickable WhatsApp mentions

by lucasmpramos open 2026-02-14 23:05 View on GitHub →
channel: whatsapp-web stale size: S
## Problem When an agent mentions someone in a WhatsApp group chat, the mention renders as either: - A raw LID number: `@91599103090759` — meaningless to humans and other agents - A raw phone number: `@+14155551234` — exposes the number, not the contact name **It never renders as a clickable `@John` mention** because the outbound path does not: 1. Resolve the phone/LID to a display name for the message text 2. Populate the Baileys `mentions[]` JID array that WhatsApp needs for clickable rendering ## Solution Add `processOutboundMentions()` to `send-api.ts` that bridges the gap between what the agent writes and what WhatsApp needs: 1. Parses `@+14155551234` / `@14155551234` patterns from outbound text 2. Resolves each phone → LID via `sock.signalRepository.lidMapping.getLIDForPN()` (Baileys built-in, already used on the inbound side for JID resolution) 3. Replaces the text with `@LID_NUMBER` — WhatsApp uses this internally to match against the `mentions` array and render the contact's display name 4. Populates the `mentions[]` JID array in the Baileys payload The key insight: WhatsApp renders `@LID_NUMBER` + a matching entry in `mentions[]` as a **clickable contact name** (e.g., `@John`). Without the `mentions` array, it's just raw text. ## Example **Before:** - Agent sends `Hey @+14155551234` → WhatsApp shows literal `@+14155551234` - Agent sends `Hey @91599103090759` → WhatsApp shows literal `@91599103090759` **After:** - Agent sends `Hey @+14155551234` → phone resolved to LID, added to mentions array → WhatsApp renders **@John** (clickable, highlighted, notifies the person) ## Changes - `src/web/inbound/send-api.ts` — new `processOutboundMentions()` + `LidResolver` type, wired into `sendMessage` - `src/web/inbound/monitor.ts` — passes `lidMapping` from `signalRepository` into `createWebSendApi` ## Backward Compatibility - If `lidMapping` is unavailable, falls back to `@s.whatsapp.net` JID (current behavior, no regression) - No changes to inbound processing - No new dependencies <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR adds outbound `@mention` resolution for WhatsApp messages, aiming to convert raw phone numbers like `@+14155551234` into clickable, highlighted contact mentions. The approach is to resolve phone numbers to LID JIDs and populate the Baileys `mentions[]` array. - **Critical interface mismatch**: `lidLookup` (`sock.signalRepository.lidMapping`) provides `getPNForLID` (LID → phone), but the new `LidResolver` type expects `getLIDForPN` (phone → LID). Because `getLIDForPN` is optional, TypeScript won't flag this — it's silently `undefined` at runtime. LID resolution will never fire, and mentions will always fall back to `@s.whatsapp.net` JIDs, which likely won't render as clickable names. - The `processOutboundMentions()` logic itself (regex parsing, deduplication, fallback) is well-structured and the fallback path ensures no regression. <h3>Confidence Score: 2/5</h3> - Safe to merge (no regression due to fallback), but the core feature will not work as intended. - The feature's primary goal — resolving phone numbers to LID JIDs for clickable WhatsApp mentions — cannot work because the Baileys lidMapping object passed at the integration point exposes the wrong method (getPNForLID instead of getLIDForPN). The fallback path prevents any runtime errors or regressions, but the PR does not deliver its stated functionality. - Pay close attention to `src/web/inbound/monitor.ts` line 373 where `lidLookup` is passed as `lidResolver` — the interface mismatch is the root cause. <sub>Last reviewed commit: ada4b0b</sub> <!-- greptile_other_comments_section --> <!-- /greptile_comment -->

Most Similar PRs