Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#2,705 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
postgresql, typescript
Domain
api, backend, databases

Research direction

Start in src/api/integrations/channel/whatsapp/whatsapp.baileys.service.ts and trace getMessage plus its seven call sites. Verify the missing-row path and how the Baileys getMessage option handles a falsy result, then check the retry lookup query and its suggested index. Done means missing messages are not relayed or treated as real messages, and the lookup is addressed as intended.

Written by the indexing model from the issue text.

Description

What happened

getMessage() returns { conversation: '' } when the message is not found. Baileys treats any
truthy return as "message found", so it relays an empty message and consumes one of the retry
attempts. On the recipient's phone the message becomes a permanent
"Waiting for this message. This may take a moment." placeholder — the retry that was supposed to
recover it delivered an empty envelope instead.

src/api/integrations/channel/whatsapp/whatsapp.baileys.service.ts (still on main today):

private async getMessage(key: proto.IMessageKey, full = false) {
  try {
    const webMessageInfo = (await this.prismaRepository.$queryRaw`
      SELECT * FROM "Message"
      WHERE "instanceId" = ${this.instanceId} AND "key"->>'id' = ${key.id}
    `) as proto.IWebMessageInfo[];
    if (full) return webMessageInfo[0];
    ...
    return webMessageInfo[0].message;
  } catch {
    return { conversation: '' };   // <-- row not found => webMessageInfo[0] is undefined
  }                                //     => `.message` throws => empty text is returned
}

Baileys, Socket/messages-recv.js:

if (msg && (await willSendMessageAgain(ids[i], participant))) {
    updateSendMessageAgainCount(ids[i], participant);   // burns 1 of maxMsgRetryCount (4)
    await relayMessage(key.remoteJid, msg, msgRelayOpts);
} else {
    logger.debug({ jid: key.remoteJid, id: ids[i] }, 'recv retry request, but message not available');
}

Returning undefined instead makes Baileys take the else branch: no attempt is consumed and
nothing is sent, so the peer can ask again and gets the real message once the row is committed.

Why the row can be missing

sendMessageWithTyping persists the row after the send, after the Chatwoot integration
round-trip and, for media, after writing the media file — while retryRequestDelayMs is 350 ms.
Baileys' in-memory recent-message cache (512 entries) usually covers this, but it is lost on every
socket restart, so after a reconnect or a re-pair the DB path is the only one left. That is exactly
when a burst of retries happens (a re-pair invalidates every peer's session), so the failure
concentrates precisely where it hurts most.

We saw this in production right after a QR re-pair: group media sent 4 minutes later reached every
participant as the "Waiting for this message" placeholder, permanently.

Suggested fix
  } catch (error) {
    this.logger.warn(`getMessage failed for ${key.id}: ${error}`);
    return undefined;
  }

All 7 call sites of this.getMessage( already handle a falsy return — and four of them get
strictly better, because today they silently receive a fake message and carry on:

call site current handling
Baileys getMessage option if (msg && ...) — relays the empty message
messages.edit f?.id
poll updates h && (...) — aggregates votes against a fake message
quoted message S && (c = S) — quotes an empty message
getBase64FromMediaMessage if (!n) throw 'Message not found' — never reached today
formatUpdateMessage t?.messageType
updateMessage if (!i) throw new BadRequestException('Message not found') — never reached today

Also worth noting: the retry lookup filters on "key"->>'id', and there is no index for it — it is
a sequential scan of Message on every retry. Adding
("instanceId", (("key"->>'id'))) took the query from 9.76 ms to 0.158 ms on a 15.8k-row table
here, and it only gets worse as the table grows.

Version

v2.3.6, self-hosted, Postgres, Chatwoot integration enabled.

Dominant language
TypeScript
Stars
9.7k
Forks
7.3k
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from evolution-foundation/evolution-api

All issues in evolution-foundation/evolution-api

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.