Honour downloadMedia=true when media download is disabled

[Elimeshi1]

The problem

With WHATSAPP_DOWNLOAD_MEDIA=false, WhatsappConfigService.mimetypes returns a single sentinel value:

get mimetypes(): string[] {
  if (!this.shouldDownloadMedia) {
    return ['mimetype/ignore-all-media'];
  }
  ...
}

It matches no real mimetype, so shouldProcessMimetype() rejects everything — which is the point. But it also means a request that explicitly asks for the media is ignored:

GET /api/{session}/chats/{chatId}/messages?downloadMedia=true
GET /api/{session}/chats/{chatId}/messages/{messageId}?downloadMedia=true

The response comes back with no media and no indication that the parameter was dropped. downloadMedia is a documented query parameter, so the caller has no way to tell whether the message had no media or the download was silently skipped.

This matters for the setup the flag exists for: media download is turned off because the volume is not worth storing, but occasionally one specific message's media is needed on demand.

The fix

A force flag threaded from the request down to the mimetype check:

if (
  this.mimetypes.length === 1 &&
  this.mimetypes[0] === IGNORE_ALL_MEDIA_MIMETYPE
) {
  return force;
}

It overrides only the global "download disabled" sentinel, never a real WHATSAPP_FILES_MIMETYPES allow list — an allow list still means what it says, and downloadMedia=true cannot smuggle a video/mp4 past a list that permits only images.

Applied to all four engines, since each defines its own processIncomingMessage / downloadMediaSafe / downloadMedia trio rather than inheriting one. Internal callers that pass a literal true/false are left alone: only a user-supplied downloadMedia sets force, so nothing changes for event-driven message processing.

The sentinel is now the exported IGNORE_ALL_MEDIA_MIMETYPE constant instead of being spelled out in config.service.ts and compared in MediaManager.ts.

Testing

tsc --noEmit and prettier clean.

The behaviour has been running in our own deployment with WHATSAPP_DOWNLOAD_MEDIA=false, where downloadMedia=true returns the media and leaving it unset still returns none. The allow-list path is untouched by construction — force is only consulted inside the sentinel branch — but I have not exercised it with a real WHATSAPP_FILES_MIMETYPES list.

Extending the same change to WEBJS and WPP is new here; our deployment only runs NOWEB and GOWS.