fix(message): find sent message indexed under alternate wid (lid/pn)

[telmedola]

Description

client.sendMessage() sometimes resolves with undefined even though the message is actually delivered to the recipient.

Root cause: in window.WWebJS.sendMessage, sending and retrieving the sent message are two separate steps:

1. WAWebSendMsgChatAction.addAndSendMsgToChat(chat, message) sends the message;
2. Msg.get(newMsgKey._serialized) looks it up in the collection to return it.

For contacts with a lid/phone-number wid pair, WhatsApp Web can index the sent message under the chat's sibling wid (lid ↔ pn), so the lookup by the original key finds nothing and the function silently returns undefined — after the message has already gone out. Callers then treat a delivered message as failed, which typically leads to duplicate sends.

Fix: when the lookup by the original key fails, the sent message is now searched:

1. in the chat's own collection by the random id part of the key (m.id.id === newMsgKey.id), which does not depend on the wid used to build the key;
2. by a key rebuilt with the alternate wid (WAWebApiContact.getAlternateUserWid), and in the sibling chat's collection.

If the message still cannot be found, the lookup context (attempted key, chat id, alternate wid, last message keys of the chat) is stored in window.WWebJS.lastSendMessageDebug as an internal diagnostic aid, and undefined is returned as before. No public API change; behavior for already-working cases is unchanged (the original lookup runs first).

Related Issue(s)

Related to #3767

Testing Summary

Test Details

Reproduced in production with a customer-service system sending messages to contacts whose getNumberId() resolves to a @lid wid: the recipient received the message, but sendMessage resolved with undefined (TypeError in our caller when reading response.id). With this patch, sendMessage returns the proper Message object for those contacts; text and media sends to regular @c.us contacts were also re-tested and behave as before. <-- ajuste conforme sua validação do novo build

Environment

• Machine OS: Debian 12 (Docker, node:20-bookworm-slim)
• Library Version: 1.34.7
• WhatsApp Web Version: 2.3000.1043191242
• Node Version: 20.20.0

Type of Change

• Dependency change (package changes such as removals, upgrades, or additions)
• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Non-code change (documentation, README, etc.)

Checklist

• My code follows the style guidelines of this project.
• All new and existing tests pass (npm test).
• Typings (e.g. index.d.ts) have been updated if necessary. (no public API change)
• Usage examples (e.g. example.js) / documentation have been updated if applicable. (not applicable)

[fernandomondo]

The real bug is that Meta changed the message payload.

Instead of returning newMsgKey._serialized, it is now returning newMsgKey.$1.

I don't know whether this change is permanent or if Meta will roll it back in the next few hours. However, if it is permanent, we'll need to update all relevant code to accept $1 as a fallback when _serialized is not available.

edit:
Actually, there's already a PR open with this fix: #201832

[telmedola]

The real bug is that Meta changed the message payload.

Instead of returning newMsgKey._serialized, it is now returning newMsgKey.$1.

I don't know whether this change is permanent or if Meta will roll it back in the next few hours. However, if it is permanent, we'll need to update all relevant code to accept $1 as a fallback when _serialized is not available.

edit: Actually, there's already a PR open with this fix: #201832

Thanks — you're right, _serialized → $1 is the actual root cause, and #201832 is the proper fix for it. I'll defer to that PR for the rename.

That said, the fallback in this PR is complementary rather than redundant: it looks the sent message up by the random id part of the key (m.id.id === newMsgKey.id), which doesn't depend on _serialized at all — so it also covers this incident and any future change to the key serialization, plus the lid/pn indexing edge case. Happy to rebase it on top of #201832 (keeping only the lookup fallbacks and the lastSendMessageDebug diagnostic) if that's useful, or close it if the maintainers prefer.