getMessage() returns { conversation: '' } on miss — Baileys relays an empty message and burns the retry, leaving "Waiting for this message" forever #2705

Activity

1. augustoadsa commented on Aug 24, 2026

   

   augustoadsa

   on Aug 24, 2026

   More actions

   Independent confirmation on v2.3.7, plus a consequence I think raises the severity of this
   issue considerably: in group chats the retry you are burning is the only mechanism that can
   ever repair a broken sender-key distribution.

   The code is still there in 2.3.7. From the running bundle:

   async getMessage(key, full = false) {
     try {
       const rows = await this.prismaRepository.$queryRaw`
         SELECT * FROM "Message" WHERE "instanceId" = ${this.instanceId} AND "key"->>'id' = ${key.id}`
       if (full) return rows[0]
       if (rows[0].message?.pollCreationMessage) { /* ... */ }
       return rows[0].message
     } catch { return { conversation: '' } }
   }

   Worth noting explicitly: on a miss the query returns [], so rows[0].message?.… throws a
   TypeError and lands in the same catch. The "not found" path and the "database error" path
   therefore converge on the same empty envelope — the miss is swallowed as if it were an error.

   Why this is worse in groups. In baileys@7.0.0-rc.9 — the version this project pins on main
   and on the 2.4.0-rc2 tag — the group sender-key bookkeeping map (sender-key-memory-<jid>@g.us)
   is written to only with true and is never invalidated by participant or identity changes; the
   comment // on participant change in group, we should do sender memory manipulation is still
   unimplemented, in rc.9 and in current master alike. The single place in the whole library that
   clears that map is sendMessagesAgain in src/Socket/messages-recv.ts:

   if (isJidGroup(remoteJid)) {
     await authState.keys.set({ 'sender-key-memory': { [remoteJid]: null } })
   }

   So the retry receipt is not merely one recovery path among several — for groups it is the only
   one. Feeding it an empty envelope consumes the recipient's limited retries without ever delivering
   real content, and once they are exhausted no further retry arrives. A transient decryption failure
   becomes permanent.

   What we observe, on a fully LID-addressed group (Evolution 2.3.7, baileys 7.0.0-rc.9, Node
   20.20.2, Redis-backed auth state, ~14 participants, all @lid):

   • Every send is accepted with no error, and a subset of members — all of them iPhone — see only
     "Waiting for this message", indefinitely (> 1 week). Android members read everything. Messages
     posted by humans in the same group are read by everyone, including the affected iPhones.
   • The group's sender-key-memory map is always 100% true — 29, 22, 30 and 22 device entries
     observed on four separate occasions, always zero false. It never self-clears, which is itself
     evidence that the retry path is not doing its job in practice.
   • Deleting that one Redis field restores delivery, confirmed on the affected handsets, 3 out of 3
     times (2026-08-03, 08-08, 08-19), and it regresses within days: 4 events in 21 days.
   • One affected iPhone user created a new WhatsApp Business registration and immediately started
     receiving the bot's group messages, with no change on our side — consistent with the map being the
     gate, since a fresh registration is a device not yet marked true.

   We now clear the map hourly from cron as a stop-gap. That is obviously not a fix, and it should not
   be necessary.

   Supporting the proposed change: returning undefined instead of { conversation: '' } is the
   right call. Two suggestions on top of it:

   1. Distinguish the miss from the error — if (!rows.length) return undefined before touching
      rows[0] — so a genuine database failure can be logged instead of silently masquerading as a
      cache miss.
   2. Log at warn when getMessage misses. Today this failure mode is completely silent on the
      sender side: the socket reports success, Message.status never leaves PENDING for group sends,
      and the only signal that anything is wrong is a human saying "I never got it".

   Happy to test a patched build against the live group.
2. AlmogCohen

   added 2 commits that reference this issue on Sep 27, 2026

   docs(fork): correct the issue references

   ...

   07d7703

   docs(fork): correct the issue references

   ...

   c559cb1