[BUG] Intermittent sticker media download failures (fetch failed / empty media key) in downloadContentFromMessage

[kaikybrofc]

Description

We are observing reproducible media-download failures for stickers in production when using downloadContentFromMessage (indirectly through command handlers).

Two recurring failure modes:

1. TypeError: fetch failed
2. Cannot derive from empty media key

This affects sticker conversion flows (sticker -> gif/png) and appears to be tied to specific incoming sticker payload shapes (some valid, some invalid/partial).

Environment

• Baileys: github:WhiskeySockets/Baileys#v7.0.0-rc10
• Node.js: v24.14.1
• npm: 11.11.0
• OS: Linux 6.8.0-107-generic (Ubuntu)
• App version: 0.1.8
• Runtime model: long-running socket process (PM2)

What We Tested

1) Runtime log evidence from command path

Command !togif is correctly parsed and executed, but fails while resolving source sticker media:

• 2026-05-10T22:56:26Z -> TypeError: fetch failed
• 2026-05-10T22:57:04Z -> TypeError: fetch failed

After adding defensive handling around source resolution, the command no longer crashes and logs this warning instead:

• 2026-05-10T22:58:30Z -> sticker convert falhou ao resolver mídia de origem with err.message = fetch failed

So the failure is consistently happening during media retrieval, not during format conversion.

2) Database sampling (message_media) + direct URL fetch tests

We sampled recent sticker records from MySQL (message_media joined with messages) and tested URL fetchability.

Observed URL patterns:

• Fully qualified https://mmg.whatsapp.net/... -> often downloadable (200)
• https://a.whatsapp.net -> fetch failed
• Relative paths like /m1/v/t24/... -> invalid as standalone URL for plain fetch

3) Baileys-level parity test (downloadContentFromMessage)

We replayed recent stored data_json objects through Baileys downloadContentFromMessage(media, 'sticker').

Representative outcomes:

• Success cases return valid WEBP buffers.
• Failure cases return:
  • fetch failed
  • Cannot derive from empty media key

This reproduces the same failure signatures seen in production command execution.

Reproduction (Minimal)

1. Capture recent incoming sticker messages and persist media payload (url, directPath, mediaKey, etc.)
2. For each payload, call:

const stream = await downloadContentFromMessage(mediaNode, 'sticker')

3. Observe that some payloads download/decrypt correctly while others fail with:

TypeError: fetch failed

or

Cannot derive from empty media key

Expected Behavior

For sticker payloads that are valid within WhatsApp message flow, Baileys should either:

1. resolve/reupload/retry media robustly, or
2. return a more specific structured failure describing which field is missing/invalid (mediaKey, URL host validity, relative URL resolution path, etc.)

Actual Behavior

For a subset of stickers, downloadContentFromMessage fails non-deterministically from application perspective due to payload shape:

• Host/URL variants that are not directly fetchable
• Payloads where media key material appears insufficient for decryption

Additional Technical Notes

• In our sample set, this is not universal failure: many stickers in same timeframe work fine.
• Failures correlate strongly with specific URL/payload variants rather than command logic.
• We currently mitigate at app level by falling back and returning user-friendly messages, but root cause remains at media retrieval/decryption boundary.

Questions for Maintainers

1. Is https://a.whatsapp.net (or relative /m1/...) expected to appear for sticker media nodes in this version?
2. Is there a recommended canonical normalization path before downloadContentFromMessage for these nodes?
3. Is there a supported media-reupload retry path specifically for sticker downloads in this scenario?
4. Are there known regressions around v7.0.0-rc10 + Node 24 for sticker fetch/decrypt?

Optional: We can provide redacted payload samples

We can share several redacted data_json payloads (working vs failing) if useful for triage.

[CSFelix]

I am facing the same issue with https://a.whatsapp.net

[kaikybrofc]

Additional field report from a production deployment (UTC), in case this helps narrow root cause.

Time window analyzed

• 2026-05-11 through 2026-05-16 00:35 UTC

Observed error

• Cannot derive from empty media key
• Thrown during media download path when calling getMediaKeys

Scale and frequency

• 1157 total occurrences in application logs
• 1114 unique message IDs (some IDs are retried/reprocessed)

Daily distribution

• 2026-05-11: 490
• 2026-05-12: 115
• 2026-05-13: 0
• 2026-05-14: 40
• 2026-05-15: 499 (largest spike)
• 2026-05-16 (until 00:35 UTC): 13

Strong pattern in affected chats

• 100 percent of occurrences came from JIDs ending with @newsletter
• We did not observe this error in group or direct chats in the same window

Message/media characteristics at failure time

• mediaNode.hasMediaKey: false in 100 percent of failing events
• mediaNode.hasDirectPath: usually true
• mediaNode.hasUrl: sometimes true, sometimes false
• Even when directPath/url are present, download still fails because mediaKey is missing

Media types impacted

• imageMessage: 870
• stickerMessage: 209
• videoMessage: 73
• audioMessage: 5

Top newsletter JIDs by recurrence in this sample

• 120363252280300733@newsletter: 209
• 120363404701403742@newsletter: 166
• 120363194378500802@newsletter: 110
• 120363337605066160@newsletter: 86

Example event shape seen repeatedly

• chatJid: newsletter
• mediaType: imageMessage or stickerMessage
• hasMediaKey: false
• hasDirectPath: true
• hasUrl: true or false
• result: Cannot derive from empty media key

Most likely causes based on telemetry

1. Newsletter media payloads are sometimes delivered without mediaKey.
2. Ordering/race between append/notify events and full media metadata availability.
3. Behavior difference between newsletter transport and regular chats.
4. Retry/reprocessing of the same message increases error volume in logs.

Operational impact

• High log noise in media pipelines
• Repeated retries on messages that are impossible to decrypt without mediaKey

If useful, I can share a fully anonymized structured sample with timestamp, media type, hasMediaKey/hasUrl/hasDirectPath flags, and message dedup markers to assist reproducibility.