fix: normalize fileName property to handle case-insensitivity#2471
fix: normalize fileName property to handle case-insensitivity#2471enzowilliam wants to merge 2 commits intoEvolutionAPI:mainfrom
Conversation
- Changed truthy check to strict equality (=== true) to properly handle string values like "false" sent by clients (e.g., n8n) - Fixed validation schema property name from 'everyOne' to 'mentionsEveryOne' to match DTO and service code Fixes EvolutionAPI#2431 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
The sendMedia endpoint had an inconsistency where: - For images: only `filename` (lowercase) worked - For documents/videos: only `fileName` (camelCase) worked This was caused by the code only checking `data.fileName` without considering that users might send `filename` (lowercase) in the JSON payload. This fix normalizes the property name at the beginning of the mediaMessage method in all three channel services: - whatsapp.baileys.service.ts - evolution.channel.service.ts - whatsapp.business.service.ts Now both `fileName` and `filename` are accepted for all media types. Closes EvolutionAPI#2459 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Reviewer's GuideNormalizes the SendMedia DTO so both Sequence diagram for sendMedia filename normalizationsequenceDiagram actor Client participant Api as MessageApi participant Chan as ChannelService participant WA as WhatsappProvider Client->>Api: POST /message/sendMedia/{instance}\nbody { fileName or filename } Api->>Chan: mediaMessage(data, file, isIntegration) alt data.fileName is defined Chan->>Chan: Build mediaData with fileName = data.fileName else data.fileName is undefined and data.filename is defined Chan->>Chan: Build mediaData with fileName = data.filename end Chan->>Chan: if file provided\nset mediaData.media = file buffer base64 Chan->>WA: Send normalized mediaData WA-->>Chan: Provider response Chan-->>Api: Normalized send result Api-->>Client: HTTP response Class diagram for updated message mention schemasclassDiagram class TextMessageSchema { +boolean mentionsEveryOne +array mentioned } class MediaMessageSchema { +boolean mentionsEveryOne +array mentioned } class PtvMessageSchema { +boolean mentionsEveryOne +array mentioned } class AudioMessageSchema { +boolean mentionsEveryOne +array mentioned } class StickerMessageSchema { +boolean mentionsEveryOne +array mentioned } class LocationMessageSchema { +boolean mentionsEveryOne +array mentioned } class PollMessageSchema { +boolean mentionsEveryOne +array mentioned } class ListMessageSchema { +boolean mentionsEveryOne +array mentioned } class ButtonsMessageSchema { +boolean mentionsEveryOne +array mentioned } TextMessageSchema <|-- MediaMessageSchema TextMessageSchema <|-- PtvMessageSchema TextMessageSchema <|-- AudioMessageSchema TextMessageSchema <|-- StickerMessageSchema TextMessageSchema <|-- LocationMessageSchema TextMessageSchema <|-- PollMessageSchema TextMessageSchema <|-- ListMessageSchema TextMessageSchema <|-- ButtonsMessageSchema Flow diagram for mentionsEveryOne handling in Baileys serviceflowchart TD A[Start building mentions list] --> B{options.mentionsEveryOne === true} B -->|yes| C[Set mentions to all group participants ids] B -->|no| D{options.mentioned has items} D -->|yes| E[Map each mentioned value to participant id] D -->|no| F[Leave mentions empty] C --> G[Continue sending message] E --> G[Continue sending message] F --> G[Continue sending message] File-Level Changes
Assessment against linked issues
Possibly linked issues
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Hey - I've found 1 issue, and left some high level feedback:
- Renaming
everyOnetomentionsEveryOneacross all message schemas may be a breaking API change for existing clients; consider either keepingeveryOneas a deprecated alias in the schema or handling both properties during validation/normalization similar to thefileName/filenameapproach. - The
mediaMessagenormalization logic forfileNameis duplicated in three services; consider extracting a shared helper or applying normalization at a DTO/validation layer to avoid drift between channel implementations. - Using
fileName: data.fileName || (data as any).filenamewill overwrite an explicitly provided empty stringfileNamewithfilename; if that matters for your API, consider using nullish coalescing (??) instead of||.
Prompt for AI Agents
Please address the comments from this code review: ## Overall Comments - Renaming `everyOne` to `mentionsEveryOne` across all message schemas may be a breaking API change for existing clients; consider either keeping `everyOne` as a deprecated alias in the schema or handling both properties during validation/normalization similar to the `fileName`/`filename` approach. - The `mediaMessage` normalization logic for `fileName` is duplicated in three services; consider extracting a shared helper or applying normalization at a DTO/validation layer to avoid drift between channel implementations. - Using `fileName: data.fileName || (data as any).filename` will overwrite an explicitly provided empty string `fileName` with `filename`; if that matters for your API, consider using nullish coalescing (`??`) instead of `||`. ## Individual Comments ### Comment 1 <location path="src/api/integrations/channel/whatsapp/whatsapp.baileys.service.ts" line_range="2981-2986" /> <code_context> + const mediaData: SendMediaDto = { + ...data, + // Normalize filename to fileName (handle case-insensitivity) + fileName: data.fileName || (data as any).filename, + }; </code_context> <issue_to_address> **suggestion:** Overriding `fileName` after spreading may mask an existing, intentionally empty `fileName` value. If `data.fileName` is an empty string (or another falsy-but-valid value), this will incorrectly fall back to `(data as any).filename`. Prefer checking only for `undefined`, e.g. `fileName: data.fileName ?? (data as any).filename`, so intentional empty values are preserved. ```suggestion public async mediaMessage(data: SendMediaDto, file?: any, isIntegration = false) { const mediaData: SendMediaDto = { ...data, // Normalize filename to fileName (handle case-insensitivity) while preserving intentional empty values fileName: data.fileName ?? (data as any).filename, }; ``` </issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| public async mediaMessage(data: SendMediaDto, file?: any, isIntegration = false) { | ||
| const mediaData: SendMediaDto = { ...data }; | ||
| const mediaData: SendMediaDto = { | ||
| ...data, | ||
| // Normalize filename to fileName (handle case-insensitivity) | ||
| fileName: data.fileName || (data as any).filename, | ||
| }; |
There was a problem hiding this comment.
suggestion: Overriding fileName after spreading may mask an existing, intentionally empty fileName value.
If data.fileName is an empty string (or another falsy-but-valid value), this will incorrectly fall back to (data as any).filename. Prefer checking only for undefined, e.g. fileName: data.fileName ?? (data as any).filename, so intentional empty values are preserved.
| public async mediaMessage(data: SendMediaDto, file?: any, isIntegration = false) { | |
| const mediaData: SendMediaDto = { ...data }; | |
| const mediaData: SendMediaDto = { | |
| ...data, | |
| // Normalize filename to fileName (handle case-insensitivity) | |
| fileName: data.fileName || (data as any).filename, | |
| }; | |
| public async mediaMessage(data: SendMediaDto, file?: any, isIntegration = false) { | |
| const mediaData: SendMediaDto = { | |
| ...data, | |
| // Normalize filename to fileName (handle case-insensitivity) while preserving intentional empty values | |
| fileName: data.fileName ?? (data as any).filename, | |
| }; |
Summary
/message/sendMedia/{instance}endpoint where thefileNameproperty was case-sensitivefilename(lowercase) workedfileName(camelCase) workedfileNameandfilenameare accepted for all media typesChanges
Added property normalization at the beginning of the
mediaMessagemethod in all three channel services:src/api/integrations/channel/whatsapp/whatsapp.baileys.service.tssrc/api/integrations/channel/evolution/evolution.channel.service.tssrc/api/integrations/channel/meta/whatsapp.business.service.tsThe fix normalizes
filenametofileNameby using:Test plan
fileNameproperty - should workfilenameproperty - should workfileNameproperty - should workfilenameproperty - should workfileNameproperty - should workfilenameproperty - should workCloses #2459
🤖 Generated with Claude Code
Summary by Sourcery
Normalize media message filename handling across channels and refine group mention options for message schemas and WhatsApp integration.
Bug Fixes:
fileNameandfilenameproperties when sending media messages across WhatsApp, Evolution, and Meta channel services.mentionsEveryOneonly applies when explicitly set to true in WhatsApp Baileys group messaging.Enhancements:
everyOnetomentionsEveryOnefor clearer and more consistent API semantics across all message types.