[NOWEB] - Media re-upload request is never sent: CDN 404/410 fails hard because Baileys checks error.status on a Boom

[haag-sondershausen]

Describe the bug

For NOWEB, GET /api/{session}/chats/{chatId}/messages/{messageId}?downloadMedia=true fails for every media message that has aged out of the WhatsApp CDN (in our measurements roughly 2.5–3 weeks after sending). WAHA passes reuploadRequest: sock.updateMediaMessage to Baileys' downloadMediaMessage (NOWEBEngineMediaProcessor.getMediaBuffer), so a 404/410 from the CDN should make the phone re-upload the file — but the re-upload request is never sent.

The root cause is in the bundled Baileys fork (devlikeapro/Baileys#fork-master-2026-04-28, src/Utils/messages.ts, downloadMediaMessage):

if (
  ctx &&
  typeof error?.status === 'number' && // treat errors with status as HTTP failures requiring reupload
  REUPLOAD_REQUIRED_STATUS.includes(error.status as number)
) {

The error comes from getHttpStream (src/Utils/messages-media.ts):

throw new Boom(`Failed to fetch stream from ${url}`, { statusCode: response.status, data: { url } })

A Boom carries the status in output.statusCode and has no .status property, so the re-upload branch is unreachable (a regression since axios was removed upstream). Upstream: WhiskeySockets/Baileys#2767 (open). A fix was proposed in WhiskeySockets/Baileys#2729, but it was closed as stale without being merged.

Version

{
  "version": "2026.8.1",
  "engine": "NOWEB",
  "tier": "CORE"
}

Steps

To Reproduce

1. NOWEB session with store.enabled: true and fullSync: true, paired to a phone with older chat history.
2. GET /api/{session}/chats/{chatId}/messages/{messageId}?downloadMedia=true for a media message older than ~3 weeks.
3. The response has media.url: null and media.error is the Boom above with output.statusCode 404 or 410 (403 for much older messages). _data.message.*.directPath is unchanged — no re-upload happened. The call takes ~12 s because MediaManager retries the fetch 5 times.

We tested 19 messages across 3 sessions: up to ~18 days old, 5 of 6 downloaded fine; from ~18–21 days on, 0 of 13 (CDN 404/410/403).

Expected behavior

On a 404/410 from the CDN, Baileys sends the media retry receipt, the phone re-uploads the file and the download succeeds — the way WhatsApp Web loads old media.

Suggested fix

In the fork's downloadMediaMessage:

const status = error?.output?.statusCode ?? error?.status
if (ctx && typeof status === 'number' && REUPLOAD_REQUIRED_STATUS.includes(status)) {

The second part of Baileys#2729 (base64 mediaKey in getMediaRetryKey) should not affect WAHA, since the NOWEB store revives Buffers via BufferJSON.reviver.

Additional context

Two things worth considering once the retry path works:

• updateMediaMessage waits for messages.media-update without a timeout (waitForMsgMediaUpdate(...) is called without timeoutMs), so a phone that never answers hangs the request (possibly related to [NOWEB] - fetch media raises timeout if media is not available on servers #857).
• MediaManager.withRetry('Fetching media', …) retries 5 times. With a working re-upload, a file the phone no longer has would trigger up to 6 retry receipts per message. Marking "Media re-upload failed by device" as nonRetriable would avoid that.

Thanks for WAHA!