Description
An incoming message was stored by the engine but never emitted as a message.any / message webhook event, and WAHA logged nothing at all while it happened.
This is not a webhook delivery failure: every POST WAHA did send in that window returned 201. The event was simply never produced.
It is also not the noisy parseMessageIdSerialized drop (Caught error, dropping value from) reported previously — that one leaves a TypeError and a stack trace in the logs. Here grep 'dropping value from' over 3 hours of container logs returns 0 matches, and there is no TypeError either. Silent to the logs, not just to the webhook.
Environment
- WAHA version:
devlikeapro/waha:latest-2026.8.1 (Core)
- Engine: WEBJS
- Session status:
WORKING for the entire window (before, during and after)
Evidence
1. The message exists in WAHA's own store.
GET /api/{session}/chats/{chatId}/messages?limit=20 returns it:
id: false_<LID>@lid_3AA125C6829E103C0780
timestamp: 1788283732 (2026-09-01 17:28:52 UTC)
body: "<a normal text message, ~65 chars>"
fromMe: false
2. No message.any event was ever emitted for it.
The WebhookSender lines in the surrounding window are exactly:
17:28:04, 17:28:31, 17:36:38, 17:49:21, 17:49:25, 17:49:33,
17:50:31, 17:50:45, 17:51:14, 17:53:07, 17:53:26, 18:11:03, 18:11:33, 18:21:16
There is no entry at 17:28:52. Every one of the above returned status code: 201.
3. WAHA logged nothing.
Between 17:28:34 and 17:29:00 there is not a single log line from the container — no info, no warn, no error.
4. It is not specific to the contact or to @lid.
Two other messages from the same contact and the same @lid JID were delivered normally and processed:
17:28:02 → false_<LID>@lid_3A67C76F4C3C0F479CCF (48 seconds before the lost one)17:53:24 → false_<LID>@lid_3A945EFA439DC04E0617 (25 minutes after)
So the loss is intermittent, not deterministic per identity, per number, or per JID namespace.
Expected behavior
A message that the engine stores in its chat history should also produce a message.any / message webhook event — or, if it is deliberately discarded, say so in the logs.
Actual behavior
The message is stored and reachable via the API, but no event is produced and nothing is logged. From the consumer's point of view the message never existed.
Why this is hard to detect downstream
Because the drop is silent on both channels (no event and no log line), log-based monitoring cannot see it by construction. We had a log-pattern watcher running (dropping value from, every 15 min); the run covering this drop reported count=0 and was correct to do so — there was nothing in the logs to find.
We ended up building a reconciliation check instead: periodically compare the lastMessage of GET /api/{session}/chats against the messages our backend actually processed. That works, but it only catches the loss while the lost message is still the newest in its chat, so it is a detection rate, not a guarantee.
Questions
- Is there a known path in the WEBJS engine where a message is written to the store but the event pipeline is skipped (e.g. a queue drop under memory pressure, a deduplication branch, or an exception swallowed before the event is built)?
- Would it be feasible to log something whenever a stored message does not produce an event? Even a single warn line would make this class visible to ordinary log monitoring.
Related but different
I can provide more logs or run specific read-only API calls against the affected instance if that helps narrow it down.
Description
An incoming message was stored by the engine but never emitted as a
message.any/messagewebhook event, and WAHA logged nothing at all while it happened.This is not a webhook delivery failure: every POST WAHA did send in that window returned
201. The event was simply never produced.It is also not the noisy
parseMessageIdSerializeddrop (Caught error, dropping value from) reported previously — that one leaves aTypeErrorand a stack trace in the logs. Heregrep 'dropping value from'over 3 hours of container logs returns 0 matches, and there is noTypeErroreither. Silent to the logs, not just to the webhook.Environment
devlikeapro/waha:latest-2026.8.1(Core)WORKINGfor the entire window (before, during and after)Evidence
1. The message exists in WAHA's own store.
GET /api/{session}/chats/{chatId}/messages?limit=20returns it:2. No
message.anyevent was ever emitted for it.The
WebhookSenderlines in the surrounding window are exactly:There is no entry at 17:28:52. Every one of the above returned
status code: 201.3. WAHA logged nothing.
Between
17:28:34and17:29:00there is not a single log line from the container — no info, no warn, no error.4. It is not specific to the contact or to
@lid.Two other messages from the same contact and the same
@lidJID were delivered normally and processed:17:28:02→false_<LID>@lid_3A67C76F4C3C0F479CCF(48 seconds before the lost one)17:53:24→false_<LID>@lid_3A945EFA439DC04E0617(25 minutes after)So the loss is intermittent, not deterministic per identity, per number, or per JID namespace.
Expected behavior
A message that the engine stores in its chat history should also produce a
message.any/messagewebhook event — or, if it is deliberately discarded, say so in the logs.Actual behavior
The message is stored and reachable via the API, but no event is produced and nothing is logged. From the consumer's point of view the message never existed.
Why this is hard to detect downstream
Because the drop is silent on both channels (no event and no log line), log-based monitoring cannot see it by construction. We had a log-pattern watcher running (
dropping value from, every 15 min); the run covering this drop reportedcount=0and was correct to do so — there was nothing in the logs to find.We ended up building a reconciliation check instead: periodically compare the
lastMessageofGET /api/{session}/chatsagainst the messages our backend actually processed. That works, but it only catches the loss while the lost message is still the newest in its chat, so it is a detection rate, not a guarantee.Questions
Related but different
WORKING.I can provide more logs or run specific read-only API calls against the affected instance if that helps narrow it down.