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.