Problem

WhatsApp increasingly addresses events with LID identifiers (<lid>@lid) instead of the phone-based JID. Business-linked accounts hit this almost exclusively, which leaves those instances with no usable chat history and live messages that never link to their chat.

This is the concrete failure behind the umbrella issue #1872.

Root cause

Two distinct problems, both in whatsapp.baileys.service.ts:

1. messages.upsert resolved @lid too late.
The swap ran after prismaRepository.message.create(), after the Chat lookup and after the Contact upsert — so all three were keyed by @lid while the swap only patched the outgoing webhook payload. The stored row was never corrected.

2. messaging-history.set never resolved @lid on messages at all.
Its chat resolution consulted only contact.phoneNumber, which history payloads frequently omit. Worse, history-sync message keys carry no remoteJidAlt and no addressingMode — verified directly against stored rows — so there is nothing on the key to resolve from.

Because chats resolved (partially) while messages did not, messages and chats ended up keyed differently and simply never joined. That is why chats appeared to contain only their most recent message.

Fix

• Resolution in messages.upsert now happens before any lookup or write. received.key itself is deliberately left untouched so protocol calls (readMessages, requestPlaceholderResend, fetchMessageHistory, media download) keep addressing the message exactly as WhatsApp delivered it; only a resolved copy is used for our own storage.
• History sync resolves through Baileys' signal-level LID store (signalRepository.lidMapping), batched once per payload and shared by chats, contacts and messages. The lookup is guarded (if (!lidStore?.getPNsForLIDs) return;) and degrades to previous behaviour if unavailable.
• Fixed a latent bug where contactsMapLidJid falls back to the contact's own id, so contact.jid could be truthy but still @lid — the old truthy check swallowed it and blocked resolution.

Results

Measured on a Business-linked instance (1101 messages, 91 chats):

The 2 remaining @lid chats have no name, no messages and no mapping in the LID store — nothing exists to resolve them to.

Live messages.upsert verified separately: LID-addressed messages in both directions, including media, resolve to the phone JID and land in the existing chat rather than creating a parallel @lid one. Unread counters and contact linkage confirmed correct.

Also included: patches/baileys+7.0.0-rc13.patch

Media on these messages was unrecoverable due to two upstream Baileys bugs (submitted separately to WhiskeySockets/Baileys):

1. downloadMediaMessage tests error?.status, but getHttpStream throws a Boom carrying the status on output.statusCode. .status is always undefined, so the media re-upload request was never sent — unreachable dead code.
2. getMediaRetryKey does not normalise a base64-string mediaKey the way its sibling getMediaKeys does. Media keys rehydrated from JSON storage are base64, so HKDF ran over the base64 characters instead of the key bytes, and WhatsApp answered DECRYPTION_ERROR.

With both applied, media inside WhatsApp's retention window downloads again — verified 10/10, output validated as genuine Ogg/Opus with byte length matching the declared size.

Testing notes / limitations

• Validated on a single Brazilian Business number on PostgreSQL. MySQL and non-BR numbering are untested.
• Resolution reads client.signalRepository.lidMapping, which is Baileys-internal. It is guarded and degrades gracefully, but it could shift across Baileys versions.
• tsc --noEmit and eslint both clean.

Summary by Sourcery

Resolve WhatsApp LID-based identifiers to phone JIDs consistently for history sync and live messages, and patch upstream Baileys media download issues.

Bug Fixes:

• Ensure history-synced messages and chats resolve @lid identifiers to phone JIDs using Baileys’ LID mapping store so they correctly join existing chats.
• Resolve @lid remoteJid and participant values to phone JIDs before chat and contact lookups in live messages.upsert so messages no longer create parallel @lid chats or orphaned contacts.
• Fix pushName resolution during history sync to fall back across both phone JIDs and LID aliases, reducing nameless messages.
• Correct handling of Baileys media download failures by inspecting Boom error status and normalizing base64 media keys so retained media can be decrypted and fetched successfully.

Enhancements:

• Introduce a shared in-memory LID-to-JID map for history sync to reuse resolved mappings across contacts, chats and messages.
• Improve guarding and logging around LID store lookups to provide safer degradation and better observability of resolution outcomes.