[GOWS] - Some messages are lost without any error
Describe the bug
Some messages are not shown in waha without any error in docker logs. The messages are on whatsapp but are not shown in the dashboard.
Here's an example:
Whatsapp has two messages between "ANDREA" and "[12/11. 14:31 etc..."
While Waha has nothing between those two messages:
Version
{
"version": "2025.11.1",
"engine": "GOWS",
"tier": "PLUS"
}
Docker Logs
There are no error shown on the docker container in those time slots I know it's not a lot to work with, if you need more details I'll try to get them to you
Hi! Could you check the @lid chat for that number? Manually via API?
We don't combine @c.us with @lid right now but likely whatsapp uses both (or you use @c.us using /api/sendText but later original app send a message to your @lid)
need to double check it
@devlikepro I have several example, it's happening quite often
{
"lid": "242xxxxxxxxxx07@lid",
"pn": "[email protected]"
}
{
"lid": "110xxxxxxxxxx72@lid",
"pn": "[email protected]"
}
I don't understand what exactly you need to check further, I think @lid is widely used now so I think it should be handled correctly. If you need something unredacted I can send you an email
Ok I found out
that some messages are returned only by passing @c.us as the chatId , while others by passing @lid. Note that it's exclusive, the ones that are missing if I use @c.us are the ones that are showing with @lid, and vice-versa.
I think that all methods that use chatId should handle the conversion automatically and work regardless.
Analyzing what we receive from "message.any" we noticed that most messages have @c.us in "id" and "from" fields
while "Chat" is identified by @s.whatsapp.net and "SenderAlt" is @lid
On the other hand, the messages that have @lid in "id" and "from" fields
have also @lid in "Chat" but @s.whatsapp.net in "SenderAlt"
I imagine you receive them as-is from the original app. Is it possibile to unify those messages ids somehow?
Also, the Chat UI in the Dashboard only displays the messages that have @c.us in the "from" field, meaning that some of them are not displayed properly because the only way to retrieve them is by @lid. Since it's always either one or the other, I think combining them in the Chat UI would be the best solution
+1
+1
[TIME] WARN (N): [Session/<SESSION_ID>/Client] Error decrypting message <MESSAGE_ID> from <USER_JID>: failed to decrypt normal message: no session found for user <USER_DEVICE_ID> {"engine":"ENGINE_NAME"}
Hi @devlikepro, I don't understand what do you mean with this warn
[TIME] WARN (N): [Session/<SESSION_ID>/Client] Error decrypting message <MESSAGE_ID> from <USER_JID>: failed to decrypt normal message: no session found for user <USER_DEVICE_ID> {"engine":"ENGINE_NAME"}
Is this what we are going to get if the cus / lid discrepancy occurs? I don't think so but could you make it clear for us? Thanks in advance