externalAdReply (Click-to-WhatsApp ads) no longer reaches the Chatwoot integration on 2.4

Start in src/api/integrations/channel/whatsapp/whatsapp.baileys.service.ts and inspect prepareMessage(), especially how contentMsg.contextInfo and quotedMessage are populated. Then read getAdsMessage() in src/api/integrations/chatbot/chatwoot/services/chatwoot.service.ts and compare the 2.3.7 and 2.4.0-rc2 behavior. Done means ad title, body, thumbnail and source URL reach Chatwoot, while plain text and quoted media context still work.

Summary

Since 2.4, messages coming from Instagram/Facebook click-to-WhatsApp ads arrive in
Chatwoot as plain text. The ad card — thumbnail, title, body, source URL — is
silently dropped. On 2.3.7 the same messages produced an attachment with the
resized thumbnail plus the ad title and link.

There is no error in the logs. The message itself is delivered; only the ad
context disappears.

Root cause

prepareMessage() in src/api/integrations/channel/whatsapp/whatsapp.baileys.service.ts
changed which field feeds messageRaw.contextInfo.

main (and 2.3.7):

const contentType = getContentType(message.message);
const contentMsg = message?.message[contentType] as any;
// ...
contextInfo: this.deserializeMessageBuffers(contentMsg?.contextInfo),

develop (and 2.4.0-rc2):

contextInfo: this.deserializeMessageBuffers(message.message?.messageContextInfo),

messageContextInfo is the WhatsApp device-metadata block (deviceListMetadata,
E2E key info). It never carries externalAdReply. The ad context lives in the
content message's own contextInfo, e.g.
message.message.extendedTextMessage.contextInfo.externalAdReply.

Why the Chatwoot side then fails

getAdsMessage() in
src/api/integrations/chatbot/chatwoot/services/chatwoot.service.ts is called as
this.getAdsMessage(body), where body is the message wrapper:

title: msg.extendedTextMessage?.contextInfo?.externalAdReply?.title
    || msg.contextInfo?.externalAdReply?.title,

The first branch never matches, because on the wrapper the content lives under
msg.message.extendedTextMessage, not msg.extendedTextMessage. So the whole
feature depended on the hoisted msg.contextInfo — precisely what the change
above repointed. getAdsMessage() now returns an object whose fields are all
undefined, the if (adsMessage && adsMessage.title || ...) branch is skipped,
and no attachment is created.

Side effect beyond ads

messageRaw?.contextInfo?.quotedMessage (same file) reads the same field, so
quote/reply context on media messages is lost as well.

Steps to reproduce

1. Run 2.4.0-rc2 with the Chatwoot integration enabled.
2. Publish an Instagram ad with a click-to-WhatsApp button.
3. Click the ad and send any text.
4. Chatwoot receives the text only. On 2.3.7 the same flow produced an
   attachment with the 320x180 thumbnail, the ad title and the source URL.

Suggested fix

Restore the previous source in prepareMessage():

const contentType = getContentType(message.message);
const contentMsg = message?.message[contentType] as any;
// ...
contextInfo: this.deserializeMessageBuffers(contentMsg?.contextInfo),

Independently, getAdsMessage() would be more robust reading
msg.message?.extendedTextMessage?.contextInfo?.externalAdReply as its first
branch, so it no longer depends on the hoisted field at all.

Environment

• Evolution API 2.4.0-rc2 (Docker, evoapicloud/evolution-api:2.4.0-rc2)
• Chatwoot 4.17.1, self-hosted
• Baileys channel, four instances
• Regression confirmed by source diff between tags 2.3.7 and 2.4.0-rc2, and
  between branches main and develop.

Workaround in use

While this is open, we patch the compiled bundles
(dist/api/integrations/channel/whatsapp/whatsapp.baileys.service.{js,mjs}) in a
derived image, replacing the expression with one that does not depend on
minified symbol names:

contextInfo: this.deserializeMessageBuffers(
  (e.message && Object.values(e.message).find(v => v && typeof v === "object" && v.contextInfo)?.contextInfo)
  ?? e.message?.messageContextInfo
)

Checked against simulated payloads: ad leads recover title / body /
thumbnailUrl / sourceUrl, plain text messages are unaffected, and quoted
media regains its stanzaId. It is running in our production instance; we have
not yet observed a live ad lead through it.

const contentType = getContentType(message.message);
const contentMsg = message?.message[contentType] as any;
// ...
contextInfo: this.deserializeMessageBuffers(contentMsg?.contextInfo),

contextInfo: this.deserializeMessageBuffers(message.message?.messageContextInfo),

title: msg.extendedTextMessage?.contextInfo?.externalAdReply?.title
    || msg.contextInfo?.externalAdReply?.title,

const contentType = getContentType(message.message);
const contentMsg = message?.message[contentType] as any;
// ...
contextInfo: this.deserializeMessageBuffers(contentMsg?.contextInfo),

contextInfo: this.deserializeMessageBuffers(
  (e.message && Object.values(e.message).find(v => v && typeof v === "object" && v.contextInfo)?.contextInfo)
  ?? e.message?.messageContextInfo
)