Baileys engine: @lid -> phone never resolves (senderPhone / contacts/:id/phone always null); #263 feature non-functional on Baileys

[ulises2k]

Summary

The @lid → phone resolution added in #263 (RESOLVE_LID_TO_PHONE, senderPhone on message.received, and GET /sessions/:id/contacts/:contactId/phone) works on the whatsapp-web.js adapter but is effectively non-functional on the Baileys engine: senderPhone and the on-demand endpoint return null even for known/saved contacts.

Environment

• OpenWA v0.4.3 (current main)
• Engine: Baileys
• RESOLVE_LID_TO_PHONE=true

Symptoms

Inbound message from an @lid sender the account has interacted with before (the same contact previously appeared by phone number, before WhatsApp's LID migration):

• message.received payload: isLidSender: true but senderPhone: null
• GET /api/sessions/:sid/contacts/<id>@lid/phone → { "contactId": "<id>@lid", "phone": null }

So isLidSender (engine-neutral detection) works, but the resolution (adapter-specific) never returns a number on Baileys — even after the contact sends a fresh message.

Root cause

The Baileys resolution only consults two in-memory maps and has no server-query / lidMapping fallback, unlike the wwebjs adapter which uses getContactLidAndPhone() (the server-query fallback that was the whole point in #263).

src/engine/adapters/baileys.adapter.ts:

async resolveContactPhone(contactId: string): Promise<string | null> {
  this.ensureReady();
  return this.sessionStore.resolvePhone(contactId);
}

src/engine/adapters/baileys-session-store.ts:

resolvePhone(id: string): string | null {
  if (id.endsWith('@s.whatsapp.net')) return this.userPart(id);
  if (id.endsWith('@lid')) {
    const pn = this.lidToPn.get(id);
    if (pn) return this.userPart(pn);
    const contactPhone = this.contacts.get(id)?.phoneNumber;
    return contactPhone ? this.userPart(contactPhone) : null;   // null when not pre-cached
  }
  return null;
}

If the lid → pn mapping isn't already in lidToPn / contacts, it returns null with no attempt to resolve. In practice those maps aren't populated for an inbound @lid sender (a fresh inbound message still yields null), so the feature never fires on Baileys.

Contrast — src/engine/adapters/whatsapp-web-js.adapter.ts uses client.getContactLidAndPhone([id]), which does a server-side query and resolves contacts even when not locally cached.

Suggested fix

Give the Baileys resolvePhone a real fallback, e.g.:

1. Populate lidToPn from inbound message metadata — Baileys exposes the PN alongside the LID (message key senderPn / participantPn, and the lid-mapping.update event / messages.upsert lid info).
2. Query Baileys' LID mapping store as a fallback: sock.signalRepository.lidMapping.getPNForLID(lid) (and/or a USync / onWhatsApp lookup), mirroring the server-query fallback the wwebjs adapter gets from getContactLidAndPhone.

Happy to test a patch on a live Baileys session.

Repro

1. Baileys session, RESOLVE_LID_TO_PHONE=true.
2. Receive a message from a contact WhatsApp now addresses as @lid (one you've messaged before).
3. Observe senderPhone: null on the payload and null from GET .../contacts/<lid>/phone.

Related: #263.

[rmyndharis]

Confirmed — thanks for the thorough, source-traced report. This is a real gap.

On main, the Baileys resolvePhone only consults the in-memory lidToPn / contacts maps (populated from messaging-history.set lidPnMappings and contacts.upsert), with no server-query fallback. So for an inbound @lid sender whose mapping isn't already cached, it returns null — whereas the whatsapp-web.js adapter resolves on demand via client.getContactLidAndPhone(). Your diagnosis (and the contrast you drew) is accurate, and the engine-neutral isLidSender detection working while the adapter-specific resolution returns null is exactly the symptom that follows.

This is also the concrete bug behind the lid↔phone resolution work being designed in #349 (a typed identity + resolution table), and it overlaps #342 (engine-neutral identity). I'm linking them so the thread stays connected: #263 (the original feature), #342, #349.

Your suggested fix is the right direction:

1. Populate lidToPn from inbound message metadata (Baileys attaches the PN alongside the LID on lid-addressed messages in recent protocol versions), and
2. add a server-query fallback via Baileys' lid mapping (e.g. signalRepository.lidMapping / a USync onWhatsApp lookup), mirroring what wwebjs gets from getContactLidAndPhone.

One implementation note: we pin @whiskeysockets/baileys@6.7.23, whose type defs lag the runtime for some LID APIs (the adapter already casts to read lidPnMappings), so the patch will need to confirm the exact runtime surface on that version. I'll scope it as a tracked fix — and I'll gladly take you up on testing a patch against a live Baileys session. 🙏

[rmyndharis]

Quick update to keep this thread current: I re-traced main at v0.4.4 and the bug still stands exactly as you diagnosed.

• src/engine/adapters/baileys-session-store.ts resolvePhone() still consults only the in-memory lidToPn / contacts maps and returns null when the mapping isn't already cached — no server-query fallback.
• resolveContactPhone() in the Baileys adapter is a thin pass-through to that method.
• lidToPn is only populated from messaging-history.set lidPnMappings and contacts.upsert, neither of which fires for a fresh inbound @lid sender — which is why you see senderPhone: null even after a new message.
• For contrast, the whatsapp-web.js adapter resolves on demand via client.getContactLidAndPhone() (the server-side query). The only onWhatsApp usage in the Baileys adapter is for number-existence checks, not lid resolution.

I also want to flag, in case it saves you time testing: PR #342 (engine-neutral identities) does not close this — it canonicalizes inbound JIDs but still relies on lidToPn being populated via history sync, so the resolution gap remains. The deeper design work in #349 (typed identity + resolution table) is also still in progress. So this is tracked as its own bugfix.

Planned fix, mirroring your suggestion:

1. Populate lidToPn from inbound message metadata (the PN Baileys attaches alongside the LID, plus the lid-mapping update event), and
2. add a server-query fallback in resolvePhone via Baileys' lid mapping store (signalRepository.lidMapping), mirroring what wwebjs gets from getContactLidAndPhone.

One caveat: we pin @whiskeysockets/baileys@6.7.23, whose type defs lag the runtime for some LID APIs (the adapter already casts to read lidPnMappings), so I'll confirm the exact runtime surface on that version before relying on it.

Your offer to test a patch on a live Baileys session is genuinely valuable here — I'll absolutely take you up on it once I have a branch ready. Thank you again for the precise, source-traced report. 🙏