Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#2,705 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
3/5
Tempo estimado
1-2 dias
Facilidade para iniciantes
76/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
postgresql, typescript
Domínio
api, backend, databases

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
TypeScript
Estrelas
9.7k
Forks
7.3k
Nenhum PR com merge em 30d

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de evolution-foundation/evolution-api

Todas as issues de evolution-foundation/evolution-api

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.