[GOWS] - Messages carrying senderKeyDistributionMessage never decrypt — silent group message loss since @lid migration

[GalaxyRuler]

Edit: re-posting the body — angle-bracket placeholders in the code blocks were stripped as HTML on first submit, which emptied out the SQL and log samples. Content is otherwise unchanged.

Describe the bug

Since WhatsApp migrated one of our group chats to @lid addressing, a consistent share of inbound group messages never decrypt. The message is stored, but Message (and RawMessage) contain only the encryption envelope and no content:

{
  "Message": {
    "senderKeyDistributionMessage": { "groupID": "GROUP_ID@g.us", "axolotlSenderKeyDistributionMessage": "..." },
    "messageContextInfo": { "deviceListMetadata": {} }
  },
  "IsReal": false,
  "Status": 4,
  "RetryCount": 0,
  "UnavailableRequestID": "",
  "Info": { "Type": "media", "MediaType": "document", "AddressingMode": "lid" }
}

The 1:1 part decrypts fine (that is where the SKDM comes from); the group skmsg payload does not. No error surfaces at the default log level, no webhook carries usable content, and GET /api/{session}/chats/{chatId}/messages/{messageId} later returns 404 Message not found — so the message cannot be recovered afterwards.

The predicate is exact

Analysing every group message since the addressing change, the split is total — this is not a correlation, it is an identity:

	decrypted	failed
Message contains senderKeyDistributionMessage	0	22
it does not	48	0

Every message that carries an SKDM fails. Every message that does not, succeeds.

Supporting observations, same dataset:

• It starts exactly at the @lid cutover. 294 messages over the preceding three months, all with AddressingMode absent (legacy PN), zero failures. From the day the group flipped to AddressingMode: "lid", failures begin immediately and never stop. Overall since then: 46 ok / 20 failed (30%).
• It is not sender-specific. 10 senders have both successes and failures under the same LID (one is 13 ok / 3 failed). Every sender that posted has a sender key stored for the group.
• It tracks sender idleness. Median gap since that sender's previous message is 36 h before a failure versus 0 h before a success — consistent with WhatsApp re-distributing the sender key when someone has been quiet, and the content of that same message being encrypted under the newly distributed key.
• The sender's next message recovers. After a failure, the same sender's following message decrypts in 12 of 14 cases — the key is usable from then on, just not for the message that delivered it.
• No retry receipt is requested. All failures have RetryCount: 0, empty UnavailableRequestID, and an empty whatsmeow_retry_buffer. The retry path does work in general — it fired 3 times across 26,815 stored messages and recovered the message every time — it simply never engages for this case, so nothing self-heals.

Why this is painful

The lost message is, by construction, the first thing a participant posts after being idle. For any workflow where people drop a document into a group and then go quiet, that is precisely the message that matters. In our case roughly one in three shared documents is destroyed before the application ever sees it, silently.

Reproducing / verifying

Against the GOWS session store (gows.db), the failure set is:

SELECT count(*) FROM gows_messages
WHERE jid = 'GROUP_ID@g.us'
  AND json_extract(data,'$.Message.senderKeyDistributionMessage') IS NOT NULL
  AND json_extract(data,'$.Message.conversation') IS NULL
  AND json_extract(data,'$.Message.extendedTextMessage') IS NULL
  AND json_extract(data,'$.Message.documentMessage') IS NULL
  AND json_extract(data,'$.Message.imageMessage') IS NULL;

Anyone seeing silent group message loss on GOWS can run that to check whether they have the same thing.

Two smaller things

1. The default log level hides it. With WAHA_LOG_LEVEL: error nothing at all is logged for these. Raising it to info surfaces GOWS engine lines. Given that the outcome is silent data loss, a warning at error level for an undecryptable message would have saved us a fortnight of not knowing.
2. Upgrading did not help. We went gows-2026.7.1 to gows-2026.8.1 specifically for the LID fixes in that release. Behaviour is unchanged (2 ok / 2 failed since, including one more lost document). The session survived the upgrade and re-authenticated normally, so this is not a pairing problem.

Possibly related but, I believe, distinct: #1625 is about messages that do decrypt but are addressed inconsistently across @c.us / @lid. These never decrypt at all.

Happy to supply anything further — I have the full message store and can run whatever query is useful.

Version

{
  "version": "2026.8.1",
  "engine": "GOWS",
  "tier": "CORE"
}

Docker Logs

Nothing is emitted for a failing message at WAHA_LOG_LEVEL: error. At info the session behaves normally around the failure:

[Manager] Session started 'SESSION_NAME'
[Session/SESSION_NAME/Client] Successfully authenticated
[Session/SESSION_NAME/Client] NCT salt is empty - forcing regular_high app-state sync

The only trace of the failure is the stored message itself and, later, a 404 Message not found when the application tries to fetch it:

GET /api/SESSION_NAME/chats/GROUP_ID%40g.us/messages/false_GROUP_ID%40g.us_MESSAGE_ID_SENDER_LID%40lid?downloadMedia=true
   -> 404 NotFoundException "Message not found"

[devlikepro]

2026.8.2 - GOWS - group messages carrying a new sender key in @lid groups were silently lost - #2242

[renatomprado]

Still reproducing on 2026.9.1 (CORE, GOWS) after the 2026.8.2 fix

Confirming the same signature described in the report, on a build that should already include the fix.

Environment

• WAHA 2026.9.1, engine GOWS, tier CORE (image created 2026-09-27)
• One busy group (@g.us, AddressingMode: "lid"), session receiving as a linked device

What I see
Rows in gows_messages for the group with Info.Type: "text" where Message contains only:

{ "senderKeyDistributionMessage": { "groupID": "…@g.us", "axolotlSenderKeyDistributionMessage": "…" },
  "messageContextInfo": { "deviceListMetadata": { … } } }

and IsReal: false, Status: 4, RetryCount: 0, UnavailableRequestID: "". RawMessage has the same envelope and no content, so the text is not recoverable from the database.

Numbers (2026-09-04 to 2026-10-01, text messages only)

• 2026-09-04 to 15: 137 texts, 47 without body (34%)
• 2026-09-16 to 30: 186 texts, 73 without body (39%)
• 2026-10-01 (partial day): 4 texts, 3 without body

The loss continues after the container moved to 2026.9.1, so 2026.8.2 did not fix it for me.

Concrete example (2026-09-30)
The group had 7 text messages that day. 5 arrived envelope-only. I confirmed all 5 against the WhatsApp app, where they are normal text messages. One sender's first message (long text) arrived envelope-only at 14:53:47 UTC, and their follow-up two seconds later (14:53:49) decrypted normally, which matches the "next message from the same sender recovers" pattern from the original report.

Other observations

• The group's messages are filtered by is_real = 1 in the list API, so these rows are also invisible there. Reading the SQLite directly is the only way to even notice them.
• No decrypt error at the default log level for these rows in the group, and no retry receipt is requested (RetryCount stays 0).

Happy to provide a redacted gows.db row or run any debug build or log level that would help narrow down why the 2026.8.2 change does not cover this case.