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

[BUG] 2.4.0-rc2: incoming text replies flattened to 'conversation' — contextInfo (stanzaId/quotedMessage/mentionedJid) lost in webhook and storage

Open
  • Is something wrong?
#2,713 0 comments 2 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
api, backend, databases

Research direction

Start at the MESSAGES_UPSERT webhook handling and the normalization path that produces messageType and the Message table payload; compare 2.4.0-rc2 with the reported 2.3.x behavior. Reproduce a text reply and a media reply, then verify that text replies retain extendedTextMessage.contextInfo, including stanzaId and mentionedJid, in both the webhook and storage.

Written by the indexing model from the issue text.

Description

Describe the bug

On 2.4.0-rc2, incoming text replies (quoted messages) are delivered to webhooks flattened: the message arrives as messageType: "conversation" with only the text and messageSecret — the extendedTextMessage wrapper and its contextInfo (stanzaId, participant, quotedMessage) are destroyed before reaching the webhook consumer. The quote relationship is unrecoverable downstream.

The same flattening happens in Evolution's own storage: our production Message table contains zero rows with messageType = 'extendedTextMessage' (2,164 conversation rows in the last 2 days alone).

Notably, replies with media still work: when a reply is an image/audio/video/document quoting another message, contextInfo is preserved inside the media wrapper (imageMessage.contextInfo, etc.). Only text replies lose the quote.

Sending works fine: POST /message/sendText with quoted: { key: { id }, message: { conversation } } delivers a proper native reply on the device (even though the sent message is also stored flattened as plain conversation — storage-side symptom of the same normalization).

Actual webhook payload (captured, credentials redacted)

The sender replied on his phone (long-press → Reply) to a text message in a group. WhatsApp on both devices shows the quote card. The messages.upsert webhook delivered:

{
  "event": "messages.upsert",
  "instance": "...",
  "data": {
    "key": {
      "remoteJid": "[email protected]",
      "fromMe": false,
      "id": "2A7E3A15419D180DE3B4",
      "participant": "2581376053441@lid",
      "participantAlt": "[email protected]",
      "addressingMode": "lid"
    },
    "pushName": "...",
    "message": {
      "messageContextInfo": {
        "threadId": [],
        "messageSecret": { "0": 221, "1": 251, "...": "..." }
      },
      "conversation": "Teste"
    },
    "messageType": "conversation",
    "messageTimestamp": 1787780498,
    "source": "unknown",
    "status": "DELIVERY_ACK",
    "contextInfo": { "threadId": [], "messageSecret": { "...": "..." } }
  }
}

Expected behavior

A text reply should be delivered as it comes from Baileys:

{
  "messageType": "extendedTextMessage",
  "message": {
    "extendedTextMessage": {
      "text": "Teste",
      "contextInfo": {
        "stanzaId": "<quoted message id>",
        "participant": "<quoted author jid>",
        "quotedMessage": { "conversation": "..." }
      }
    }
  }
}

This worked on v2.3.x (we have integrations built on contextInfo.stanzaId and contextInfo.mentionedJid that were functional before upgrading).

Steps to reproduce

  1. Run evoapicloud/evolution-api:2.4.0-rc2 (Docker, Postgres provider).
  2. Webhook enabled with MESSAGES_UPSERT.
  3. From a phone that participates in a group (group using addressingMode: "lid" in our case), long-press any text message → Reply → send a text reply.
  4. Observe the webhook payload: messageType is conversation, no contextInfo.stanzaId/quotedMessage.
  5. Also check the Message table: the row is stored as {"conversation": "..."} only.
  6. Counter-test: reply with a photo quoting a message → imageMessage.contextInfo arrives intact.

Side effect of the same (or related) regression: mentionedJid for text mentions is also lost, since it lives in the same discarded contextInfo.

Environment

  • Evolution API: 2.4.0-rc2 (evoapicloud/evolution-api:2.4.0-rc2)
  • Deploy: Docker Compose (evolution + postgres:15 + redis)
  • Provider: Baileys (WhatsApp Web), single instance, group with addressingMode: "lid"
  • Downgrade to 2.3.7 is not viable for us: instances stopped working there after WhatsApp's LID migration (which motivated the upgrade to rc2).

Happy to provide more captured payloads or test a patched build.

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.