Fix/interactive devicesent #2382
Open
+63
−31
Conversation
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
Contributor
Reviewer's GuideRefactors WhatsApp button message construction to support multiple interactive button types (reply, PIX, CTA) with stricter validation and unified message building, while preserving media header support and send-with-typing behavior. Class diagram for updated BaileysStartupService buttonMessage handlingclassDiagram
class BaileysStartupService {
+mapType Map~string,string~
+buttonMessage(data SendButtonsDto) Promise~proto.IMessage~
+prepareMediaMessage(options PrepareMediaOptions) Promise~PreparedMediaMessage~
+sendMessageWithTyping(number string, message proto.IMessage, options SendMessageOptions) Promise~proto.IMessage~
}
class SendButtonsDto {
+number string
+title string
+description string
+footer string
+thumbnailUrl string
+buttons SendButtonDto[]
+delay number
+quoted any
+mentionsEveryOne boolean
+mentioned string[]
}
class SendButtonDto {
+type string %% reply | pix | url | call | copy
+label string
+value string
}
class PrepareMediaOptions {
+mediatype string %% image
+media string
}
class PreparedMediaMessage {
+message PreparedMediaPayload
}
class PreparedMediaPayload {
+imageMessage any
}
class SendMessageOptions {
+delay number
+presence string
+quoted any
+mentionsEveryOne boolean
+mentioned string[]
}
class proto_IMessage {
}
BaileysStartupService --> SendButtonsDto : uses
BaileysStartupService --> SendButtonDto : validates
BaileysStartupService --> PrepareMediaOptions : creates
BaileysStartupService --> PreparedMediaMessage : uses
BaileysStartupService --> SendMessageOptions : creates
BaileysStartupService --> proto_IMessage : builds
Flow diagram for WhatsApp buttonMessage validation and constructionflowchart TD
A[start buttonMessage] --> B[Check buttons array exists and has length > 0]
B -->|invalid| Z1[Throw BadRequestException At least one button is required]
B -->|valid| C[Scan buttons to detect types]
C --> C1[Set hasReplyButtons]
C1 --> C2[Set hasPixButton]
C2 --> C3[Set hasCTAButtons for url, call, copy]
C3 --> D{hasReplyButtons}
D -->|yes| D1[Check total buttons <= 3]
D1 -->|no| Z2[Throw BadRequestException Maximum of 3 reply buttons allowed]
D1 -->|yes| D2{hasCTAButtons or hasPixButton}
D2 -->|yes| Z3[Throw BadRequestException Reply buttons cannot be mixed with CTA or PIX buttons]
D2 -->|no| E
D -->|no| E[Proceed]
E --> F{hasPixButton}
F -->|yes| F1[Check total buttons == 1]
F1 -->|>1| Z4[Throw BadRequestException Only one PIX button is allowed]
F1 -->|1| F2{hasReplyButtons or hasCTAButtons}
F2 -->|yes| Z5[Throw BadRequestException PIX button cannot be mixed with other button types]
F2 -->|no| G[Build PIX nativeFlowMessage with single PIX button]
G --> H[Call sendMessageWithTyping and return]
F -->|no| I[Proceed]
I --> J{hasCTAButtons}
J -->|yes| J1[Check total buttons <= 2]
J1 -->|no| Z6[Throw BadRequestException Maximum of 2 CTA buttons allowed]
J1 -->|yes| J2{hasReplyButtons}
J2 -->|yes| Z7[Throw BadRequestException CTA buttons cannot be mixed with reply buttons]
J2 -->|no| K[Proceed]
J -->|no| K[Proceed]
K --> L[Optionally prepare media header from thumbnailUrl]
L --> M[Map all buttons to nativeFlowMessage buttons]
M --> N[Build final interactiveMessage body, footer, header, nativeFlowMessage]
N --> O[Call sendMessageWithTyping and return]
Z1 --> X[end]
Z2 --> X
Z3 --> X
Z4 --> X
Z5 --> X
Z6 --> X
Z7 --> X
H --> X
O --> X[end]
File-Level Changes
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 2 issues, and left some high level feedback:
- There appears to be a stray
aqui?line left in the method body, which should be removed to avoid confusing future readers. - The PIX-specific branch builds a very similar
nativeFlowMessageto the generic case; consider extracting a small helper to construct this structure so the button/params assembly is defined in one place. - The button-type validation rules (reply/PIX/CTA combinations and limits) are embedded inline in
buttonMessage; consider encapsulating this validation into a dedicated function to make the business rules easier to read and maintain.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- There appears to be a stray `aqui?` line left in the method body, which should be removed to avoid confusing future readers.
- The PIX-specific branch builds a very similar `nativeFlowMessage` to the generic case; consider extracting a small helper to construct this structure so the button/params assembly is defined in one place.
- The button-type validation rules (reply/PIX/CTA combinations and limits) are embedded inline in `buttonMessage`; consider encapsulating this validation into a dedicated function to make the business rules easier to read and maintain.
## Individual Comments
### Comment 1
<location> `src/api/integrations/channel/whatsapp/whatsapp.baileys.service.ts:3313` </location>
<code_context>
- if (data.buttons.length === 0) {
- throw new BadRequestException('At least one button is required');
- }
+ aqui?
- const hasReplyButtons = data.buttons.some((btn) => btn.type === 'reply');
</code_context>
<issue_to_address>
**issue (bug_risk):** Remove the stray `aqui?` line, as it looks like leftover debug text and will break compilation.
This token isn’t valid TypeScript and will cause a syntax error; please delete it.
</issue_to_address>
### Comment 2
<location> `src/api/integrations/channel/whatsapp/whatsapp.baileys.service.ts:3322-3323` </location>
<code_context>
- const hasPixButton = data.buttons.some((btn) => btn.type === 'pix');
+ const hasReplyButtons = data.buttons.some((btn) => btn.type === 'reply');
+ const hasPixButton = data.buttons.some((btn) => btn.type === 'pix');
+ const hasCTAButtons = data.buttons.some(
+ (btn) => btn.type === 'url' || btn.type === 'call' || btn.type === 'copy',
+ );
</code_context>
<issue_to_address>
**suggestion (bug_risk):** The new CTA detection and validation logic no longer guards against mixing PIX/reply with any future or unknown button types.
Previously, `hasOtherButtons` treated any non-`reply`/`pix` type as “other”, so reply/PIX could not be mixed with *any* other button type. Now `hasCTAButtons` only covers `url`/`call`/`copy`, so any new or existing types outside this list can be mixed with reply/PIX without validation catching it. If reply/PIX must remain exclusive with all other types, either keep a generic `hasOtherButtons` check alongside the CTA check, or treat any unsupported `btn.type` as “other” in the validation logic.
Suggested implementation:
```typescript
const hasReplyButtons = data.buttons.some((btn) => btn.type === 'reply');
const hasPixButton = data.buttons.some((btn) => btn.type === 'pix');
const hasCTAButtons = data.buttons.some(
(btn) => btn.type === 'url' || btn.type === 'call' || btn.type === 'copy',
);
// Treat any non-reply/non-pix button type as "other" to guard against future/unknown types
const hasOtherButtons = data.buttons.some(
(btn) => btn.type !== 'reply' && btn.type !== 'pix',
);
if ((hasReplyButtons || hasPixButton) && hasOtherButtons) {
throw new BadRequestException(
'Reply and PIX buttons cannot be combined with other button types',
);
}
```
1. If there is existing validation later in `buttonMessage` that attempted to prevent mixing `reply`/`pix` with other types (e.g., relying on a prior `hasOtherButtons` or only on `hasCTAButtons`), remove or adjust it to avoid duplicate/conflicting checks, since this new `hasOtherButtons` guard now centralizes that rule.
2. If `hasCTAButtons` is intended to drive any CTA-specific behavior (like building different payload structures), ensure that code uses the new `hasCTAButtons` variable defined here rather than recomputing or assuming specific types elsewhere.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
src/api/integrations/channel/whatsapp/whatsapp.baileys.service.ts
Outdated
Show resolved
Hide resolved
Comment on lines
3322
to
3323
| const hasCTAButtons = data.buttons.some( | ||
| (btn) => btn.type === 'url' || btn.type === 'call' || btn.type === 'copy', |
Contributor
There was a problem hiding this comment.
suggestion (bug_risk): The new CTA detection and validation logic no longer guards against mixing PIX/reply with any future or unknown button types.
Previously, hasOtherButtons treated any non-reply/pix type as “other”, so reply/PIX could not be mixed with any other button type. Now hasCTAButtons only covers url/call/copy, so any new or existing types outside this list can be mixed with reply/PIX without validation catching it. If reply/PIX must remain exclusive with all other types, either keep a generic hasOtherButtons check alongside the CTA check, or treat any unsupported btn.type as “other” in the validation logic.
Suggested implementation:
const hasReplyButtons = data.buttons.some((btn) => btn.type === 'reply');
const hasPixButton = data.buttons.some((btn) => btn.type === 'pix');
const hasCTAButtons = data.buttons.some(
(btn) => btn.type === 'url' || btn.type === 'call' || btn.type === 'copy',
);
// Treat any non-reply/non-pix button type as "other" to guard against future/unknown types
const hasOtherButtons = data.buttons.some(
(btn) => btn.type !== 'reply' && btn.type !== 'pix',
);
if ((hasReplyButtons || hasPixButton) && hasOtherButtons) {
throw new BadRequestException(
'Reply and PIX buttons cannot be combined with other button types',
);
}- If there is existing validation later in
buttonMessagethat attempted to prevent mixingreply/pixwith other types (e.g., relying on a priorhasOtherButtonsor only onhasCTAButtons), remove or adjust it to avoid duplicate/conflicting checks, since this newhasOtherButtonsguard now centralizes that rule. - If
hasCTAButtonsis intended to drive any CTA-specific behavior (like building different payload structures), ensure that code uses the newhasCTAButtonsvariable defined here rather than recomputing or assuming specific types elsewhere.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
📋 Description
🔗 Related Issue
Closes #(issue_number)
🧪 Type of Change
🧪 Testing
📸 Screenshots (if applicable)
✅ Checklist
📝 Additional Notes
Summary by Sourcery
Refine WhatsApp interactive button message handling with clearer validation rules and unified message construction.
Bug Fixes:
Enhancements: