How to resolve @lid to phone JID in messaging-history.set / messages.upsert append?

[devDanRod]

Hi everyone.

I'm using @whiskeysockets/baileys with syncFullHistory: true.

My goal is to recover historical messages after reconnecting a session, using messaging-history.set and messages.upsert type append.

The history is working and messages are being recovered after my cutoff date. The problem is that some fromMe messages sent from the physical phone return only a LID JID:

key.remoteJid = "219743428550712@lid"

In those messages, key fields are only:

["remoteJid", "fromMe", "id"]

I tried:

• key.remoteJidAlt when remoteJid endsWith @lid
• key.senderPn
• key.participantPn
• key.participantAlt
• contacts from messaging-history.set
• lid-mapping.update
• sock.signalRepository.lidMapping.getPNForLID
• fallback to LID for audit

But for some historical messages, no phone JID is available.

Example log:

[HISTORY CONTATO RESOLVIDO]
{
"id": "A50BC002FED4B9A5F8F61681489EA07D",
"fromMe": true,
"remoteJid": "219743428550712@lid",
"jidContato": "219743428550712@lid",
"origemResolucao": "lid_sem_mapeamento"
}

[HISTORY PROCESSANDO]
{
"direcao": "ENVIADA",
"remetente": "555196314037",
"destinatario": "219743428550712",
"temTexto": true,
"temMidia": false,
"data": "2026-05-12T12:51:58.000-03:00"
}

Question:
Is there any reliable way in Baileys v7 to resolve this @lid to the phone JID when remoteJidAlt and contacts mapping are not provided?
Or is storing the LID as fallback the expected behavior?

[srijii]

This is expected with WhatsApp MD history sync.

In Baileys v7 there isn’t a fully reliable way to resolve every historical "@lid" back to a phone-number JID if WhatsApp didn’t send the mapping data in the history payload.

You already checked basically all available sources:

• "remoteJidAlt"
• "participantPn"
• "senderPn"
• "lid-mapping.update"
• "signalRepository.lidMapping"
• contacts/app-state sync

For some historical "fromMe" messages, WhatsApp only returns:

{
"remoteJid": "xxx@lid",
"fromMe": true,
"id": "..."
}

with no PN metadata attached at all.

When that happens, Baileys has nothing left to resolve against. The mapping simply was never included in the sync data sent by WhatsApp.

So yes, storing the "@lid" as fallback is the correct behavior here.

The only way to later resolve it is if:

• WhatsApp sends a future mapping update
• the contact becomes active again
• newer messages include PN metadata
• you keep your own persistent LID ↔ PN cache over time

But from the Baileys side alone, there’s no guaranteed recovery path for those older history-only LIDs.