Describe the bug
Follow-up to #2242 (closed, fix listed in 2026.8.2). On 2026.9.1 (CORE, GOWS) group text messages that carry a senderKeyDistributionMessage are still stored without content in a @lid group, about 35% of the group's texts. I also left a comment on #2242 with the same data.
Affected rows in gows_messages have Info.Type: "text" and a Message with only:
{ "senderKeyDistributionMessage": { "groupID": "…@g.us", "axolotlSenderKeyDistributionMessage": "…" },
"messageContextInfo": { "deviceListMetadata": { … } } }
plus IsReal: false, Status: 4, RetryCount: 0, UnavailableRequestID: "". RawMessage has the same envelope and no content, so the text cannot be recovered from the database.
Numbers (2026-09-04 to 2026-10-01, text messages only)
| Period |
Texts |
Without body |
| 2026-09-04 to 15 |
137 |
47 (34%) |
| 2026-09-16 to 30 |
186 |
73 (39%) |
| 2026-10-01 (partial day) |
4 |
3 |
The loss continues after the container moved to 2026.9.1 (image created 2026-09-27).
Concrete example (2026-09-30)
The group had 7 text messages that day and 5 arrived envelope-only. I confirmed all 5 in 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 that sender's follow-up two seconds later (14:53:49) decrypted normally. This matches the "the sender's next message recovers" pattern from #2242.
Other observations
- The list API (
GET /api/{session}/chats/{id}/messages) only returns is_real = 1 rows, so these messages are invisible there. Only reading the SQLite directly reveals them.
- No decrypt error at the default log level for these rows in the group, and no retry receipt is requested (
RetryCount stays 0).
Expected behavior
Messages carrying a new sender key in @lid groups should decrypt (or trigger a retry receipt), as described as fixed in 2026.8.2.
Versions
- WAHA
2026.9.1, engine GOWS, tier CORE
- Group
AddressingMode: "lid", session receiving as a linked device
Happy to provide a redacted gows.db row or run any debug build or log level that would help.
Describe the bug
Follow-up to #2242 (closed, fix listed in
2026.8.2). On2026.9.1(CORE, GOWS) group text messages that carry asenderKeyDistributionMessageare still stored without content in a@lidgroup, about 35% of the group's texts. I also left a comment on #2242 with the same data.Affected rows in
gows_messageshaveInfo.Type: "text"and aMessagewith only:{ "senderKeyDistributionMessage": { "groupID": "…@g.us", "axolotlSenderKeyDistributionMessage": "…" }, "messageContextInfo": { "deviceListMetadata": { … } } }plus
IsReal: false,Status: 4,RetryCount: 0,UnavailableRequestID: "".RawMessagehas the same envelope and no content, so the text cannot be recovered from the database.Numbers (2026-09-04 to 2026-10-01, text messages only)
The loss continues after the container moved to
2026.9.1(image created 2026-09-27).Concrete example (2026-09-30)
The group had 7 text messages that day and 5 arrived envelope-only. I confirmed all 5 in 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 that sender's follow-up two seconds later (14:53:49) decrypted normally. This matches the "the sender's next message recovers" pattern from #2242.
Other observations
GET /api/{session}/chats/{id}/messages) only returnsis_real = 1rows, so these messages are invisible there. Only reading the SQLite directly reveals them.RetryCountstays 0).Expected behavior
Messages carrying a new sender key in
@lidgroups should decrypt (or trigger a retry receipt), as described as fixed in2026.8.2.Versions
2026.9.1, engine GOWS, tier COREAddressingMode: "lid", session receiving as a linked deviceHappy to provide a redacted
gows.dbrow or run any debug build or log level that would help.