WhatsApp identifies some accounts by a LID β a linked/privacy identifier β instead of the classic phone-number JID. Which shape shows up for a contact isn't fixed forever: accounts migrate to LID over time. Code keyed by phone number gets a clean, silent miss for anything that now arrives as a LID β no exception, just "not found."
function naiveLookup(store, jid) {
if (!isPhoneJid(jid)) return undefined; // LIDs never match a phone-keyed store
return store.get(phoneFromJid(jid));
}
That function does exactly what it was written to do. The bug isn't in the lookup β it's the assumption baked into the store's key: that every contact is always addressable by phone number. Once any fraction of your contacts migrate to LID, that assumption is quietly wrong for them, and nothing tells you which ones. This is a real, ongoing migration β the same class of report has independently surfaced across more than one actively-maintained WhatsApp automation library.
node check.js --demo
Zero dependencies, no network β three known contacts, one migrated to a LID, checked two ways.
Against your own data (export the JIDs your system has seen as a plain JSON array):
node check.js --jids-file jids.json
It classifies how many are @lid vs @s.whatsapp.net and reports what fraction of your own contact graph is already exposed to this β without touching a network.
This exact shape has independently surfaced as reports across more than one actively-maintained WhatsApp automation library β phone-keyed lookups, message history, or dedupe breaking as LID adoption grows, with no error raised at the point of failure.