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

[juniorpagedown]

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": "1203634028...@g.us",
      "fromMe": false,
      "id": "2A7E3A15419D180DE3B4",
      "participant": "2581376053441@lid",
      "participantAlt": "5562...@s.whatsapp.net",
      "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.