fix: normalize fileName property to handle case-insensitivity#2471
Open
enzowilliam wants to merge 2 commits into
Open
fix: normalize fileName property to handle case-insensitivity#2471enzowilliam wants to merge 2 commits into
enzowilliam wants to merge 2 commits into
Conversation
Contributor
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
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
Contributor
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.
Comment on lines
+2981
to
+2986
| 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, | ||
| }; |
Contributor
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.
Suggested change
| 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, | |
| }; |
Member
|
Hi! As part of our PR triage, we noticed the Check Code Quality workflow has not run on this PR (it requires maintainer approval for first-time external contributors, which we've now enabled). To trigger CI:
Once CI runs and is green I'll re-review for merge. Thanks! |
Member
|
O fix de normalização de Bloqueador antes do merge:
Nits (não-bloqueantes):
|
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 evolution-foundation#2459 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
…e as deprecated alias - Add src/utils/normalizeSendMessageOptions.ts with normalizeFileName (uses undefined-check so intentional empty fileName is preserved) and resolveMentionsEveryOne (accepts everyOne alias and logs a one-shot deprecation warning). - Apply normalizeFileName in baileys, evolution and meta mediaMessage services, removing the duplicated (data as any).filename cast. - Restore backward compatibility for everyOne: schemas accept it as a deprecated alias, DTOs expose it as @deprecated, and baileys uses resolveMentionsEveryOne when computing mentions. - Fix unrelated axios AxiosHeaderValue type errors surfacing in pre-commit tsc (baileys + chatwoot content-type header casts). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
enzowilliam
force-pushed
the
fix/filename-property-inconsistency
branch
from
ebdcace to
06d5057
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.