fix(baileys): resolve Brazilian 9th digit lost in LID/PN mapping (#2687) - #2688
Open
IgorLimaJesus wants to merge 2 commits into
Open
Conversation
Contributor
Reviewer's GuideAdjusts Brazilian phone number normalization and Baileys WhatsApp JID/cache handling so valid 13-digit BR mobile numbers keep their 9th digit and are preferred over legacy 12-digit JIDs in cache and message routing. Sequence diagram for Baileys BR JID selection preferring 13-digit mobilessequenceDiagram
participant BaileysStartupService
participant Baileys_onWhatsApp
BaileysStartupService->>Baileys_onWhatsApp: onWhatsApp(user.number)
Baileys_onWhatsApp-->>BaileysStartupService: verify (list of jids)
BaileysStartupService->>BaileysStartupService: OnWhatsAppDto(numberVerified?.jid || user.jid)
alt [user.number is 13-digit BR mobile and numberJid is 12-digit @s.whatsapp.net]
BaileysStartupService->>BaileysStartupService: numberJid = user.number@s.whatsapp.net
end
BaileysStartupService-->>BaileysStartupService: OnWhatsAppDto(numberJid)
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:
- The Brazilian number formatting logic is now duplicated in both
ChannelStartupService.formatBRNumberandutils/createJid.formatBRNumber; consider centralizing this in a shared helper to avoid divergence and make future updates easier. - The new BR handling logic relies on several magic indices and numeric thresholds (
jid[4],firstDigit >= 6,startsWith('55'), etc.); adding intermediate variables or small helper functions with descriptive names would make the conditions clearer and reduce the risk of subtle off‑by‑one bugs.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The Brazilian number formatting logic is now duplicated in both `ChannelStartupService.formatBRNumber` and `utils/createJid.formatBRNumber`; consider centralizing this in a shared helper to avoid divergence and make future updates easier.
- The new BR handling logic relies on several magic indices and numeric thresholds (`jid[4]`, `firstDigit >= 6`, `startsWith('55')`, etc.); adding intermediate variables or small helper functions with descriptive names would make the conditions clearer and reduce the risk of subtle off‑by‑one bugs.
## Individual Comments
### Comment 1
<location path="src/utils/onWhatsappCache.ts" line_range="24-27" />
<code_context>
- const numberWithDigit =
- number.slice(4, 5) === '9' && number.length === 13 ? number : `${number.slice(0, 4)}9${number.slice(4)}`;
- const numberWithoutDigit = number.length === 12 ? number : number.slice(0, 4) + number.slice(5);
+ let numberWithDigit = number;
+ let numberWithoutDigit = number;
+
+ if (number.length === 13 && number.slice(4, 5) === '9') {
+ numberWithDigit = number;
+ numberWithoutDigit = `${number.slice(0, 4)}${number.slice(5)}`;
</code_context>
<issue_to_address>
**issue (bug_risk):** Avoid pushing duplicate numbers into `numbersAvailable` when no transformation is applied.
With the new branching, there are scenarios where both `numberWithDigit` and `numberWithoutDigit` stay equal to the original `number` (e.g., certain 12- or 13-digit BR numbers that don't meet the transformation conditions), so the same value can be pushed twice into `numbersAvailable`. If callers assume distinct variants or use the list for lookups, this can cause subtle bugs. Either deduplicate before pushing or only push the second variant when it differs from the first.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
IgorLimaJesus
force-pushed
the
fix/2687-brazilian-9th-digit-lid-mapping
branch
from
August 13, 2026 15:58
2cae956 to
9b94b49
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
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
Fixed Brazilian 9th digit handling and LID/PN mapping resolution in Baileys integration:
Fixed
formatBRNumberstripping the 9th digit:src/utils/createJid.tsandsrc/api/services/channel.service.tsthat stripped the 9th digit ('9') from Brazilian mobile numbers with area codes (DDD) ≥ 31 and subscriber numbers starting with ≥ 7 (e.g. converting5547989211984into invalid554789211984).formatBRNumberto preserve valid 13-digit Brazilian mobile numbers (55+ DDD + 9 + 8 digits) across all area codes (11-99) and add '9' only when formatting legacy 12-digit mobile numbers.Cache and JID Resolution (
onWhatsappCache.ts&whatsapp.baileys.service.ts):getAvailableNumbersandsaveOnWhatsappCacheto prevent existing 13-digit BR JIDs from being downgraded to 12-digit JIDs when updating cache records.whatsappNumberresolution inwhatsapp.baileys.service.tsto prioritize 13-digit BR mobile JIDs over 12-digit legacy JIDs returned by BaileysonWhatsAppchecks, ensuring outbound messages target valid recipient JIDs and receiveSERVER_ACK/DELIVERY_ACKinstead of remainingPENDING.🔗 Related Issue
Closes #2687
🧪 Type of Change
🧪 Testing
📸 Screenshots (if applicable)
✅ Checklist
📝 Additional Notes
evolution-api:local).Summary by Sourcery
Fix Brazilian WhatsApp number handling to preserve valid 13-digit mobile JIDs and prefer them over legacy 12-digit mappings in Baileys integration.
Bug Fixes: