Media sent through the API can never be downloaded back, and the request hangs forever

[AndreGMarra]

Version: CodeChat 1.3.6 · Baileys 7.0.0-rc.9, also reproduced on rc13 and rc14

What happens

POST /chat/mediaData/{instance}?binary=true never completes for messages the instance itself sent (keyFromMe: true). The client receives a partial body and then the connection just hangs until it times out on its own — no error, no EOF.

Two separate problems are stacked here:

1. Decryption fails

Error: error:1C800064:Provider routines::bad decrypt
    at Decipheriv.final (node:internal/crypto/cipher:193:29)
    at Transform.final [as _final] (.../@whiskeysockets/baileys/lib/Utils/messages-media.js:486:31)
  reason: 'bad decrypt',
  code: 'ERR_OSSL_BAD_DECRYPT'

2. The error handler crashes instead of closing the response

ERROR [uncaughtException]
  Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client
      at ServerResponse.json (.../express/lib/response.js:252:15)
      at Transform.<anonymous> (.../dist/src/whatsapp/routers/chat.router.js:151:79)

Streaming has already begun when decryption fails, so res.json(...) throws and the response is never terminated.

The media itself is fine

Downloading the encrypted file directly from the url in the message payload returns it complete and intact:

HTTP=200 bytes=77402 time=0.14s

That matches exactly what is expected: fileLength 77381 → 77392 (padded to the 16-byte AES block) + 10 byte MAC = 77402. So this is neither a network nor a CDN problem.

Consistent with that, the bytes that do reach the client stop at 77376 — precisely the largest 16-byte boundary below 77381, i.e. everything decrypts except the final block.

Incoming media (keyFromMe: false) on the same instance downloads and decrypts without any issue.

Reproduce

1. Send an image through POST /message/sendMedia/{instance}
2. Wait for the messages.upsert webhook and take the numeric id
3. POST /chat/mediaData/{instance}?binary=true with that message's keyId
4. The request hangs; the log shows both errors above

Suggested fixes

• Terminate the response when it has already started. Guarding on res.headersSent and destroying/ending the stream instead of calling res.json() would at least turn this into a fast failure rather than a hang, and would stop the uncaught exception. This alone is worth fixing on its own, since any error mid-stream currently leaves the connection open.
• Investigate why the stored mediaKey for self-sent messages fails to decrypt, while the same instance decrypts received media correctly.

[AndreGMarra]

While investigating the above, we ran into a second, unrelated bug on a neighbouring endpoint — reporting it here rather than opening a separate issue, but happy to split it out if you prefer.

chat/readMessages scans the entire message table

The route validates the payload against a schema that requires ids:

// src/validate/validate.schema.ts
export const readMessageForIdSchema: JSONSchema7 = {
  properties: { ids: { type: 'array', minItems: 1, ... } },
  required: ['ids'],
};

But the service that handles it reads messageId:

// src/whatsapp/services/whatsapp.service.ts
public async readMessages(data: ReadMessageIdDto) {
  const messages = await this.repository.message.findMany({
    where: { id: { in: data.messageId } },   // undefined when the caller sends `ids`
  });

A caller that follows the schema sends ids, so data.messageId is undefined.
Prisma treats { in: undefined } as no filter, so findMany matches the whole
message table instead of the requested rows.

Effect: on a fresh instance this returns quickly and the endpoint looks like it
works. On an instance with real history it takes long enough that callers time out,
the messages are never marked as read, and the server absorbs a full table scan on
every call. In our case that was one scan per conversation opened by an agent.

ReadMessageIdDto declares messageId: number[], so either the schema or the DTO
and service are the ones that need to change — they currently disagree on the
field name.

We are working around it by sending both fields, which satisfies the schema and
gives the service the field it reads.