fix: download media through the page instead of decrypting it again

[DenysSamoiliuk]

The problem

Attachment downloads fail on WhatsApp Web 2.3000.x. From node the failure is invisible — the page hands back nothing but a minified class name, so the API answers t: t.

There are two independent causes behind that.

1. The message is never found. The build indexes the Msg collection under a key the serialized id no longer matches, so Msg.get(serializedId) misses. whatsapp-web.js then falls back to Msg.getMessagesById(), whose IndexedDB lookup rejects the id:

DataError: Failed to execute 'get' on 'IDBObjectStore': No key or key range specified.

That class is minified, which is where the opaque t: t comes from.

2. Re-decrypting uses stale key material. downloadManager.downloadAndMaybeDecrypt has to be fed directPath/encFilehash/mediaKey. Once the page has run a media retry, the fresh values live on msg.mediaObject, not on the message — so the key read off msg decrypts to garbage and WhatsApp's own sniffer reports:

InvalidMediaFileType: Unexpected mimetype application/octet-stream for media type image
MediaDecryptionError: decryptMedia: hmac mismatch

The fix

Resolve the message in the page: by serialized id, then by the classic three-part key, then by scanning the collection the chat already holds, matching on id.id — which no build has renamed. The IndexedDB fallback is never reached.

Then let the page own the crypto. msg.downloadMedia() already decrypts and parks the blob in WhatsApp's own cache, so read it from InMemoryMediaBlobCache / mediaObject.mediaBlob instead of decrypting a second time. This is the same move upstream made in wwebjs/whatsapp-web.js#201697, which is on main but not in any release yet.

Waiting is keyed on the blob being there, not on mediaStage:

• cache eviction leaves RESOLVED behind with nothing to read, so the stage cannot gate the call
• the page is asked again on every round — when several media arrive at once the first request goes nowhere and the stage never moves, so passive polling can only time out
• REUPLOADING is waited out without asking again, since the page is already re-uploading
• mediaData disappearing mid-download is one more stage to sit through, not a TypeError

Bounded by a new MEDIA_RESOLVE_TIMEOUT_MS (default 10s). Every failure now names its own cause, in the log and in the error the caller gets, instead of a minified class name.

Testing

tests/mediaDownload.test.js — 16 cases against a fake page that behaves like the broken build: each resolution path, the IndexedDB fallback never being reached, re-decryption never being reached, cache eviction, a dropped request, REUPLOADING, mediaData vanishing, and each failure reason.

npm test  → 55 passed
npx eslint src tests

Running in production on a busy line since the fix landed: 169 of 169 attachments failed in 24h before, zero after.