fix(meta): use continue instead of return when processing status batches - #2715
Open
vin1i wants to merge 1 commit into
Open
fix(meta): use continue instead of return when processing status batches#2715vin1i wants to merge 1 commit into
vin1i wants to merge 1 commit into
Conversation
WhatsApp Cloud API delivers statuses in batches; a return inside the for-await loop silently dropped all remaining items when one item hit a guard (group ignore, message not found, or after handling a delete). Replaced with continue, matching the Baileys channel pattern. Closes evolution-foundation#2700
Contributor
Reviewer's guide (collapsed on small PRs)Reviewer's GuideUpdates Meta Cloud API status-batch control flow so group-filtered statuses, unknown messages, and completed delete events affect only the current item instead of silently preventing subsequent statuses from being processed. Flow diagram for per-item Meta status batch processingflowchart TD
A[Meta status batch] --> B[Process current status]
B --> C{groups_ignore and group status?}
C -->|Yes| D[continue to next status]
C -->|No| E{Message required and not found?}
E -->|Yes| D
E -->|No| F{MESSAGES_DELETE handled?}
F -->|Yes| D
F -->|No| G[Process status and emit updates]
G --> H{More statuses?}
D --> H
H -->|Yes| B
H -->|No| I[Finish batch]
File-Level Changes
Possibly linked issues
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
Contributor
There was a problem hiding this comment.
Hey - I've reviewed your changes and they look great!
Sourcery assessment
Needs a human reviewer. The change allows later items in a status batch to be processed instead of aborting the entire batch when one item is skipped. If that control flow is wrong, subsequent message records or related processing could occur and would not be removed by reverting, though the resulting data and effects are bounded and repairable.
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
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
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
The WhatsApp Cloud API (Meta Business channel) delivers message status updates in batches: a single webhook payload can contain multiple entries in
received.statuses. InBusinessStartupService.messageHandle, the loopfor await (const item of received.statuses)usedreturnin three places where per-item skipping was intended, so a single item hitting one of these paths silently aborted processing of every remaining status in the same batch (while still returning200to Meta):groups_ignoreguard: one group (@g.us) status dropped all subsequent non-group statuses in the batch.!findMessageguard: a status for a message not present in the database (e.g. sent outside Evolution, directly via the Graph API, or from the WhatsApp Business app on the phone) dropped the rest of the batch. This is the most impactful case, since Meta commonly batches statuses for several messages into one payload. One "foreign" wamid arriving first meant delivery and read receipts went missing for messages Evolution does own, with nothing in the logs.MESSAGES_DELETEbranch: after correctly handling a delete event, the remaining items in the batch were never processed, so theirMESSAGES_UPDATEevents were not emitted, not persisted tomessageUpdate, and not forwarded to Chatwoot or per-message webhooks.This PR replaces those three
returnstatements withcontinue, so each guard skips only the current item. In all three sites,returnwas the last statement on its code path within the iteration, socontinueis behaviorally identical for the current item and only restores processing of the remaining items.This also matches the pattern already used in the Baileys channel service (
whatsapp.baileys.service.ts), whosemessages.updatehandler usescontinuefor the identical per-item guards, including the same groups-ignore check.Related Issue
Closes #2700
Type of Change
Testing
Verification performed:
npm run lint:check,npm run db:generateandnpm run buildall pass locally (same steps as thecheck_code_qualityCI workflow).MESSAGES_UPDATEevent, nomessageUpdaterow, no per-message webhook call); with this change it is processed.Screenshots (if applicable)
N/A, control-flow-only change.
Checklist
Additional Notes
There is a related but distinct remaining weakness: an exception thrown inside the loop (for example the per-message
axios.post(findMessage.webhookUrl, message)at the end of an iteration, or a Prisma error) propagates to the method's outertry/catchand also aborts the remaining batch. I intentionally kept this PR limited to the fix proposed in the issue to keep the diff minimal. If maintainers would like, I can submit a follow-up wrapping each iteration in atry/catchso one failing item cannot abort the batch.