Message.downloadMedia() throws opaque r: r for all incoming media

[LC-Duarte]

Issue Priority

High (immediate attention needed)

Issue Description

Message.downloadMedia() throws an opaque r: r error for every incoming media message. This reproduces with directly sent and forwarded images and PDF documents.

The client remains connected and receives text messages normally. The failure is isolated to media download. Without a try/catch around msg.downloadMedia(), the rejected promise reaches triggerUncaughtException and terminates the Node.js process. Catching it prevents the crash but leaves the message without media data.

Observed stack:

node:internal/process/promises:391
    triggerUncaughtException(err, true /* fromPromise */);
    ^

r: r
    at #evaluate (.../puppeteer-core/lib/cjs/puppeteer/cdp/ExecutionContext.js:391:56)
    at async ExecutionContext.evaluate (.../ExecutionContext.js:277:16)
    at async IsolatedWorld.evaluate (.../IsolatedWorld.js:100:16)
    at async CdpFrame.evaluate (.../api/Frame.js:362:20)
    at async CdpPage.evaluate (.../api/Page.js:830:20)
    at async Message.downloadMedia (.../whatsapp-web.js/src/structures/Message.js:518:24)

This started suddenly after working earlier on the same day, with no application or dependency update. The same application code and lockfile had previously downloaded forwarded media successfully.

I also tested a strict archived WhatsApp Web snapshot to rule out a local-cache fallback:

• Live version observed: 2.3000.1043163628
• Strict remote snapshot: 2.3000.1043159177-alpha
• webVersionCache: remote with strict: true

The client connected successfully with the archived snapshot, but downloadMedia() failed in the same way. Recreating the Docker containers, deleting the LocalAuth session, scanning a new QR code, and testing direct/forwarded image/PDF messages did not change the result.

Steps To Reproduce

1. Initialize a client using LocalAuth and Chromium.
2. Wait for the ready event.
3. Send an image or PDF to the connected account, either directly or by forwarding it.
4. In the message handler, check msg.hasMedia and call await msg.downloadMedia().
5. Observe Puppeteer's ExecutionContext.evaluate reject with the opaque error r: r.
6. If the call is not caught, Node.js terminates through triggerUncaughtException.

Code Sample

const { Client, LocalAuth } = require('whatsapp-web.js');

const client = new Client({
    authStrategy: new LocalAuth({ dataPath: './session' }),
    puppeteer: {
        headless: true,
        executablePath: '/usr/bin/chromium-browser',
        args: ['--no-sandbox', '--disable-setuid-sandbox', '--disable-dev-shm-usage'],
    },
});

client.on('message', async (msg) => {
    if (!msg.hasMedia) return;

    const media = await msg.downloadMedia();
    console.log(media?.mimetype, media?.data?.length);
});

client.initialize();

Environment

• WhatsApp Account Type: unavailable at report time
• Authentication Strategy: LocalAuth
• whatsapp-web.js Version: 1.34.7
• WhatsApp Web Version: 2.3000.1043163628; also reproduced with strict archived 2.3000.1043159177-alpha
• Browser Type: Chromium
• Browser Version: 149.0.7827.53
• Computer OS Version: Alpine Linux 3.23.4, Docker Linux ARM64
• Phone OS Version: unavailable at report time
• Node.js Version: 20.20.2

Checklist

• I use the latest released version of whatsapp-web.js.
• I searched open issues for downloadMedia, downloadAndMaybeDecrypt, media download, and the opaque r error and found no clear duplicate.
• I verified the failure originates inside Message.downloadMedia() / Puppeteer page evaluation, not in downstream application handling.

[shashmithx]

Sane issue here

[vladkucherov]

Same here

[Nesta78]

Same here ... don't know how to debug ...

[MuhammedShibilM786]

Same issue here too

Yesterday around 111:40 pm ist it's working fine , but after few minutes i just restarted my server, I got this issue

MESSAGE RECEIVED:

OCR Failure r: r

at #evaluate (/data/data/com.termux/files/home/bot_versionfor_kdnglr/node_modules/whatsapp-web.js/node_modules/puppeteer-core/lib/cjs/puppeteer/cdp/ExecutionContext.js:391:56)

at async ExecutionContext.evaluate (/data/data/com.termux/files/home/bot_versionfor_kdnglr/node_modules/whatsapp-web.js/node_modules/puppeteer-core/lib/cjs/puppeteer/cdp/ExecutionContext.js:277:16)

at async IsolatedWorld.evaluate (/data/data/com.termux/files/home/bot_versionfor_kdnglr/node_modules/whatsapp-web.js/node_modules/puppeteer-core/lib/cjs/puppeteer/cdp/IsolatedWorld.js:100:16)

at async CdpFrame.evaluate (/data/data/com.termux/files/home/bot_versionfor_kdnglr/node_modules/whatsapp-web.js/node_modules/puppeteer-core/lib/cjs/puppeteer/api/Frame.js:362:20)

at async CdpPage.evaluate (/data/data/com.termux/files/home/bot_versionfor_kdnglr/node_modules/whatsapp-web.js/node_modules/puppeteer-core/lib/cjs/puppeteer/api/Page.js:830:20)

at async Message.downloadMedia (/data/data/com.termux/files/home/bot_versionfor_kdnglr/node_modules/whatsapp-web.js/src/structures/Message.js:517:24)

at async Client.<anonymous> (/data/data/com.termux/files/home/bot_versionfor_kdnglr/index.js:1474:34)

Now all are my ai image analysation and verification of payment report and all are freezed

My clients are shouting mere

What will I do now to solve, anyone have any ideas?

[Itayp1]

same here with every method also with get cheats

[wandsmire]

Root cause: WhatsApp's 2026-07 Web update renamed the internal serialized-id getter id._serialized → id.$1.
Because of that rename, message.id._serialized is now undefined, so Message.downloadMedia() passes undefined as the message id into the page evaluate → WhatsApp's internal lookup blows up with the opaque r: r. The same rename also breaks getChats() and anything else that reads ._serialized on a WID/message-key object.
Fix: backfill _serialized from $1 everywhere ids enter.

1. Add a normalizer and apply it in the structure constructors (Message, Chat, Contact, Channel, Broadcast, ClientInfo, GroupNotification):
   // Base.js
   static _normalizeId(id) {
   if (id && id._serialized == null && id.$1 != null) {
   return Object.assign({}, id, { _serialized: id.$1 });
   }
   return id;
   }

// e.g. Message.js constructor
this.id = Base._normalizeId(data.id);

2. For page-side reads (inside pupPage.evaluate, in Client.js and Injected/Utils.js), use a _serialized || $1 fallback, e.g.:
   const senderUserJid = sender._serialized || sender.$1;

This is the same approach as fork PR Eonus21#143. Applied it against 1.34.7 and media download + getChats work again.

[bscdaox]

Same issue.

[rodbarrdaniel-coder]

lo mismo me pasa

[sergiosalper]

Causa raiz: A atualização web do WhatsApp de julho de 2026 renomeou o getter interno de ID serializado id._serialized para id.$1. Devido a essa renomeação, message.id._serialized agora está indefinido, fazendo com que Message.downloadMedia() passe undefined como o ID da mensagem para a avaliação da página. Isso causa um erro na busca interna do WhatsApp com o valor opaco r: r. A mesma renomeação também quebra o getChats() e qualquer outro método que leia ._serialized em um objeto WID/chave de mensagem. Correção: Preencha _serialized com o valor de $1 em todos os locais onde os IDs são inseridos.

1. Adicione um normalizador e aplique-o nos construtores das estruturas (Message, Chat, Contact, Channel, Broadcast, ClientInfo, GroupNotification):
   // Base.js
   static _normalizeId(id) {
   if (id && id._serialized == null && id.$1 != null) {
   return Object.assign({}, id, { _serialized: id.$1 });
   }
   return id;
   }

// Exemplo: construtor Message.js this.id = Base._normalizeId(data.id);

2. Para leituras do lado da página (dentro de pupPage.evaluate, em Client.js e Injected/Utils.js), use um fallback _serialized || $1, por exemplo:
   const senderUserJid = sender._serialized || sender.$1;

Essa abordagem é a mesma do fork PR Eonus21#143 . Apliquei-a na versão 1.34.7 e o download de mídia e o getChats voltaram a funcionar.

Estava a horas tentando resolver com ajuda de IA e nada.
Essa resposta resolveu o problema, apenas apliquei sua orientação e consegui corrigi, está baixando a imagem e conversas tudo como antes.
Muito obrigado

[JazaelPP92]

Root cause: WhatsApp's 2026-07 Web update renamed the internal serialized-id getter id._serialized → id.$1. Because of that rename, message.id._serialized is now undefined, so Message.downloadMedia() passes undefined as the message id into the page evaluate → WhatsApp's internal lookup blows up with the opaque r: r. The same rename also breaks getChats() and anything else that reads ._serialized on a WID/message-key object. Fix: backfill _serialized from $1 everywhere ids enter.

1. Add a normalizer and apply it in the structure constructors (Message, Chat, Contact, Channel, Broadcast, ClientInfo, GroupNotification):
   // Base.js
   static _normalizeId(id) {
   if (id && id._serialized == null && id.$1 != null) {
   return Object.assign({}, id, { _serialized: id.$1 });
   }
   return id;
   }

// e.g. Message.js constructor this.id = Base._normalizeId(data.id);

2. For page-side reads (inside pupPage.evaluate, in Client.js and Injected/Utils.js), use a _serialized || $1 fallback, e.g.:
   const senderUserJid = sender._serialized || sender.$1;

This is the same approach as fork PR Eonus21#143. Applied it against 1.34.7 and media download + getChats work again.

I can confirm this issue.

I was using:

• whatsapp-web.js@1.34.7
• Node.js 20.x
• Puppeteer 24.38.0

After the WhatsApp Web update in July 2026, media messages were detected correctly:

message.hasMedia = true
message.type = "image"

but calling:

await message.downloadMedia();

failed with the same opaque error:

ERROR downloadMedia
r: r

I debugged the message ID and found that the internal serialized ID is no longer available under _serialized.

Before the change, the library expected:

message.id._serialized

but now WhatsApp Web provides:

message.id.$1

Example:

message.id: {
  fromMe: false,
  remote: 'XXXXXXXX@lid',
  id: 'XXXXXXXX',
  '$1': 'false_XXXXXXXX@lid_XXXXXXXX'
}

_serialized: undefined
$1: false_XXXXXXXX@lid_XXXXXXXX

As a temporary workaround, I restored _serialized before calling downloadMedia():

if (message.id && !message.id._serialized && message.id.$1) {
    message.id._serialized = message.id.$1;
}

const media = await message.downloadMedia();

After this change, downloadMedia() started working again and images were successfully downloaded.

The proposed _normalizeId() approach looks like the correct long-term fix because it restores compatibility globally for Message, Chat, Contact, and other structures instead of requiring individual workarounds.

Thanks for investigating this issue.