#2730·Baileys

[BUG] Linked device cannot decrypt inbound group messages — sender key fetch returns 404

Author: globalassistCreated Jul 28, 2026Updated Sep 10, 2026

[BUG] Linked device cannot decrypt inbound group messages — sender key fetch returns 404

Environment

  • Baileys version: 7.0.0-rc13 (npm latest)
  • Node version: 20.x
  • Auth: useMultiFileAuthState (file-based session storage)
  • Mode: Bot (linked device, paired via QR)
  • Session persistence: Long-running, multiple restarts, no phone-switch involved

Scenario

Hermes Agent (WhatsApp bot) is linked as a secondary device via QR pairing. It uses a dedicated bot phone number. The bot successfully:

  • Sends group messages (outbound ✅)
  • Sends and receives DMs with individual allowed users (inbound/outbound DM ✅)
  • Receives and decrypts group messages from some groups ✅

But there is one group where all inbound messages are silently dropped — the bridge cannot decrypt them.

Observed behavior

Bridge log (bridge.js):

 Requested sender keys for "Family Chat" (5 participants)
...
{"level":50,"time":...,"pid":...,"hostname":"localhost",
 "error":{"data":404,"isBoom":true,"isServer":true,
  "output":{"statusCode":500,"payload":{"statusCode":500,"error":"Internal Server Error",
   "message":"An internal server error occurred"},"headers":{}}},
 "msg":"transaction failed, rolling back"}

Bridge /chat/:id endpoint response:

json
{"name":"Family Chat","isGroup":true,"participants":[]}

Note: participants is an empty array — the bridge has no group metadata.

Gateway side:

  • Group messages are not received (the bridge's /messages endpoint drops them because msg.message === null at line 538 of bridge.js and they are silently continue-d)
  • No "No session found to decrypt message" error is logged — the message never makes it past the null check

The bot HAS E2EE sender keys for OTHER groups, just not for this specific group.

Analysis

The bridge requests sender keys for the group (visible as "Requested sender keys for ...") but the WhatsApp server responds with HTTP 404 on the key request. The "transaction failed, rolling back" error corresponds to the sender-key fetch failing.

Because the bridge never obtains valid sender keys for this group:

  1. SKDM (Sender Key Distribution Message) is never sent to group members
  2. Inbound messages from other participants arrive as encrypted skmsg payloads
  3. Baileys cannot decrypt → msg.message = null
  4. bridge.js silently drops the message (line 538: if (!msg.message) continue;)

Key difference from related issues

This is NOT the same as:

  • #2506 (retry decryption) — the issue is initial key fetch, not retry
  • #2704 (stuck after phone switch) — sender keys were never successfully fetched for this group

In #2704, the bot had working group encryption and lost it after a member's phone switch. In our case, the bot has sender keys for other groups but the WhatsApp server returns 404 when fetching keys for this specific group — even though the bridge IS a participant and can send messages to it.

Steps to reproduce

  1. Pair a bot as a linked device
  2. Add the bot to a group chat
  3. Have a group member send a message
  4. Observe: bridge requests sender keys → gets 404 → message silently dropped
  5. Bot can send to the group but never receive

Expected behavior

Sender keys should be fetchable for any group the bot is a participant in. The WhatsApp server should not return 404 when the bot requests sender keys for a group it belongs to.

Workarounds attempted

  • syncFullHistory: true — no effect on existing sessions
  • Various getMessage implementations — placeholder return works for retry but doesn't help initial key fetch
  • Multiple bridge restarts and session resets — persistent across all

Additional context

  • The bot uses LID format (@lid) for contacts; group ID is <group_id>@g.us
  • Individual DMs work perfectly
  • Outbound group messaging works (the bridge can encrypt and send)
  • The bridge has sender keys and sessions for multiple other groups
  • This has persisted through multiple bridge restarts and Baileys version updates (rc9 through rc13)