| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
… destructive JSON cloning
Reviewer's guide (collapsed on small PRs)
Reviewer's GuideRemoves destructive JSON cloning in the WhatsApp Baileys patchMessageBeforeSending hook so that list messages adjust their listType in-place without breaking Baileys’ Protobuf Long instances, and tightens one equality check to use strict comparison. Sequence diagram for WhatsApp list message sending after removing JSON cloningsequenceDiagram
actor Client
participant ApiServer
participant BaileysStartupService
participant BaileysEncoder
Client->>ApiServer: POST /message/sendList
ApiServer->>BaileysStartupService: patchMessageBeforeSending(message)
BaileysStartupService->>BaileysStartupService: check message.deviceSentMessage.message.listMessage.listType
alt deviceSentMessage listType is PRODUCT_LIST
BaileysStartupService->>BaileysStartupService: mutate listType to SINGLE_SELECT (in place)
end
BaileysStartupService->>BaileysStartupService: check message.listMessage.listType
alt message listType is PRODUCT_LIST
BaileysStartupService->>BaileysStartupService: mutate listType to SINGLE_SELECT (in place)
end
BaileysStartupService-->>ApiServer: patched message (Long instances preserved)
ApiServer->>BaileysEncoder: encode(message)
BaileysEncoder->>BaileysEncoder: call Long.isZero() on timestamps and ids
BaileysEncoder-->>ApiServer: encoded payload
ApiServer-->>Client: success response
Class diagram for BaileysStartupService patchMessageBeforeSending changeclassDiagram
class BaileysStartupService {
+patchMessageBeforeSending(message)
}
class Message {
+DeviceSentMessage deviceSentMessage
+ListMessage listMessage
}
class DeviceSentMessage {
+InnerMessage message
}
class InnerMessage {
+ListMessage listMessage
}
class ListMessage {
+ListType listType
}
class ListType {
<<enumeration>>
+PRODUCT_LIST
+SINGLE_SELECT
}
BaileysStartupService ..> Message : patches
Message o-- DeviceSentMessage
Message o-- ListMessage
DeviceSentMessage o-- InnerMessage
InnerMessage o-- ListMessage
ListMessage --> ListType
File-Level Changes
Possibly linked issues
Tips and commands Interacting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
Sorry, something went wrong.
There was a problem hiding this comment.
Hey - I've found 1 issue, and left some high level feedback:
Please address the comments from this code review:
## Overall Comments
- Since this change relies on mutating the original `message` object instead of cloning, double-check that no callers assume `patchMessageBeforeSending` is side-effect free; if they do, you may want to document or refactor those call sites.
- Consider adding a brief inline comment near the removed `JSON.parse(JSON.stringify(message))` explaining that cloning breaks Baileys `Long` instances, so future refactors don’t reintroduce a similar pattern.
## Individual Comments
### Comment 1
<location path="src/api/integrations/channel/whatsapp/whatsapp.baileys.service.ts" line_range="684" />
<code_context>
- if (message.listMessage?.listType == proto.Message.ListMessage.ListType.PRODUCT_LIST) {
- message = JSON.parse(JSON.stringify(message));
-
+ if (message.listMessage?.listType === proto.Message.ListMessage.ListType.PRODUCT_LIST) {
message.listMessage.listType = proto.Message.ListMessage.ListType.SINGLE_SELECT;
}
</code_context>
<issue_to_address>
**suggestion:** Consider consolidating the two listType checks into a small helper to avoid divergence.
There are two separate places converting `PRODUCT_LIST` to `SINGLE_SELECT` (for `deviceSentMessage.message.listMessage` and for `message.listMessage`). Extracting a helper like `normalizeListType(listMessage)` and using it in both cases would reduce duplication and keep behavior consistent if we need to update related properties or adapt to future proto/WhatsApp changes.
Suggested implementation:
```typescript
message.deviceSentMessage?.message?.listMessage?.listType === proto.Message.ListMessage.ListType.PRODUCT_LIST
) {
normalizeListType(message.deviceSentMessage.message.listMessage);
}
normalizeListType(message.listMessage);
```
To fully implement this change, you also need to:
1. Define the `normalizeListType` helper in this file (either at module scope or as a private method on the relevant class, depending on existing patterns). For example, at module scope:
```ts
function normalizeListType(listMessage?: proto.Message.IListMessage | null): void {
if (listMessage?.listType === proto.Message.ListMessage.ListType.PRODUCT_LIST) {
listMessage.listType = proto.Message.ListMessage.ListType.SINGLE_SELECT;
}
}
```
or as a method:
```ts
private normalizeListType(listMessage?: proto.Message.IListMessage | null): void {
if (listMessage?.listType === proto.Message.ListMessage.ListType.PRODUCT_LIST) {
listMessage.listType = proto.Message.ListMessage.ListType.SINGLE_SELECT;
}
}
```
2. If you choose the method form, update the usages in the replaced block to `this.normalizeListType(...)` instead of `normalizeListType(...)`.
Place the helper near related WhatsApp/Baileys message-handling utilities to match existing code organization.
</issue_to_address>
Sorry, something went wrong.
…ation#2461) Removes destructive JSON.parse(JSON.stringify(message)) cloning in patchMessageBeforeSending that caused this.isZero errors. Replaces with a clean normalizeListType() helper function. Upstream PR: evolution-foundation#2461 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…Sending JSON.parse(JSON.stringify(message)) was stripping prototypes from protobuf Long objects, causing 'TypeError: this.isZero is not a function' when sendList encoded outbound messages and silent delivery failures on sendButtons. Replace the round-trip with an in-place normalizeListType helper. Cherry-picked from upstream PR evolution-foundation#2461.
…Sending Replaces JSON.parse(JSON.stringify(message)) clones with in-place mutation. The clone destroyed protobuf Long prototypes causing "TypeError: this.isZero is not a function" when sending lists/buttons in v2.3.6. Backport of upstream PR evolution-foundation#2461 (evolution-foundation#2461). Unblocks /message/sendList endpoint for our SaaS WhatsApp button workflows. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
LGTM — clean refactor extracting normalizeListType, removes destructive JSON cloning.
Sorry, something went wrong.
… destructive JSON cloning (evolution-foundation#2461) * fix(whatsapp): resolve this.isZero error in list messages by removing destructive JSON cloning * refactor: extract listType normalization into a helper function (cherry picked from commit 8e7e13d)
| Back | FazBrowse Home | New Git URL |
📋 Description
This PR resolves the TypeError: this.isZero is not a function crash that occurs when attempting to send list messages via the /message/sendList/ endpoint.
Root Cause:
Inside src/api/integrations/channel/whatsapp/whatsapp.baileys.service.ts, the patchMessageBeforeSending hook was using JSON.parse(JSON.stringify(message)) to clone the message payload before modifying the listType. This destructive cloning operation stripped the prototype methods from underlying Protobuf Long objects (which Baileys uses for timestamps and message IDs). When Baileys later attempted to encode the message, it called .isZero() on what it expected to be a Long instance, resulting in a crash.
Fix:
Removed the JSON.parse(JSON.stringify()) calls. The code now directly mutates the listType property on the existing message object, preserving the prototype chain of all nested Protobuf instances and allowing Baileys to encode the message successfully.
🔗 Related Issue
Closes #(issue_number) (Note: Replace with the actual issue number if you opened one, e.g., #2188 or #2351)
🧪 Type of Change
🧪 Testing
📸 Screenshots (if applicable)
N/A
✅ Checklist
📝 Additional Notes
This specifically addresses the remaining /message/sendList/ failures reported in v2.3.6 and v2.3.7. Note that PR #2105 previously attempted to fix this.isZero by simplifying the logger, but it did not resolve this specific issue because the crash here occurs during the patchMessageBeforeSending Protobuf encoding phase, well before the logger is invoked.
Summary by Sourcery
Bug Fixes: