Fix Typebot message routing for @lid JIDs#2264
Fix Typebot message routing for @lid JIDs#2264DavidsonGomes merged 2 commits intoevolution-foundation:developfrom
Conversation
O Typebot não respondia mensagens vindas de JIDs que terminam com "@lid", apenas "@s.whatsapp.net". O comportamento ocorria porque o número era sempre extraído via: remoteJid.split('@')[0] Com a atualização do WhatsApp Web, algumas mensagens de mídia chegam com JID "@lid", e nesses casos o JID completo precisa ser mantido. Ajuste realizado: ANTES: number: remoteJid.split('@')[0] DEPOIS: number: remoteJid.includes('@lid') ? remoteJid : remoteJid.split('@')[0] Com essa condição, mensagens vindas de ambos os formatos passam a ser tratadas corretamente pelo Typebot.
Reviewer's guide (collapsed on small PRs)Reviewer's GuideAdjusts Typebot WhatsApp routing so that messages from JIDs ending with '@lid' are handled correctly by preserving the full JID instead of stripping the suffix, while keeping the existing behavior for '@s.whatsapp.net' JIDs. Sequence diagram for WhatsApp JID handling in BaseChatbotServicesequenceDiagram
actor User
participant WhatsAppClient
participant WhatsAppBackend
participant BaseChatbotService
participant WhatsappInstance
User->>WhatsAppClient: Send media or text message
WhatsAppClient->>WhatsAppBackend: Deliver message
WhatsAppBackend->>BaseChatbotService: webhook with remoteJid
alt JID_ends_with_lid
BaseChatbotService->>BaseChatbotService: number = remoteJid
BaseChatbotService->>WhatsappInstance: audioWhatsapp_or_mediaMessage_or_textMessage(number)
else Standard_JID_s_whatsapp_net
BaseChatbotService->>BaseChatbotService: number = remoteJid_split_at_at_index_0
BaseChatbotService->>WhatsappInstance: audioWhatsapp_or_mediaMessage_or_textMessage(number)
end
WhatsappInstance-->>WhatsAppBackend: Dispatch reply
WhatsAppBackend-->>WhatsAppClient: Deliver reply
WhatsAppClient-->>User: Show Typebot response
Flow diagram for number extraction from remoteJidflowchart TD
A[Receive_message_with_remoteJid] --> B{remoteJid_includes_lid}
B -->|yes| C[Set_number_to_remoteJid]
B -->|no| D[Set_number_to_remoteJid_split_at_at_index_0]
C --> E[Call_instance_method_with_number]
D --> E[Call_instance_method_with_number]
File-Level Changes
Possibly linked issues
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Hey there - I've reviewed your changes - here's some feedback:
- The
remoteJid.includes('@lid') ? remoteJid : remoteJid.split('@')[0]logic is repeated in multiple places; consider extracting this into a small helper (e.g.,getNumberFromJid(remoteJid)) to centralize the behavior and avoid future inconsistencies. - Using
includes('@lid')may match unintended JIDs; if the requirement is specifically for@lidJIDs, consider using a stricter check likeremoteJid.endsWith('@lid')to avoid false positives.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The `remoteJid.includes('@lid') ? remoteJid : remoteJid.split('@')[0]` logic is repeated in multiple places; consider extracting this into a small helper (e.g., `getNumberFromJid(remoteJid)`) to centralize the behavior and avoid future inconsistencies.
- Using `includes('@lid')` may match unintended JIDs; if the requirement is specifically for `@lid` JIDs, consider using a stricter check like `remoteJid.endsWith('@lid')` to avoid false positives.
## Individual Comments
### Comment 1
<location> `src/api/integrations/chatbot/base-chatbot.service.ts:214` </location>
<code_context>
if (mediaType === 'audio') {
await instance.audioWhatsapp({
- number: remoteJid.split('@')[0],
+ number: remoteJid.includes('@lid') ? remoteJid : remoteJid.split('@')[0],
delay: (settings as any)?.delayMessage || 1000,
audio: url,
</code_context>
<issue_to_address>
**issue (bug_risk):** Guard against false positives by using a stricter check than `includes('@lid')`.
`includes('@lid')` will treat any JID that merely contains that substring as already normalized, even if it appears in the middle or multiple times. If you only want to preserve true LID JIDs, a stricter condition like `remoteJid.endsWith('@lid')` (or another explicit pattern check) would avoid these false positives.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| if (mediaType === 'audio') { | ||
| await instance.audioWhatsapp({ | ||
| number: remoteJid.split('@')[0], | ||
| number: remoteJid.includes('@lid') ? remoteJid : remoteJid.split('@')[0], |
There was a problem hiding this comment.
issue (bug_risk): Guard against false positives by using a stricter check than includes('@lid').
includes('@lid') will treat any JID that merely contains that substring as already normalized, even if it appears in the middle or multiple times. If you only want to preserve true LID JIDs, a stricter condition like remoteJid.endsWith('@lid') (or another explicit pattern check) would avoid these false positives.
|
Bom dia! Com essa alteração, a API está enviando de forma correta o telefone para o typebot ? Pois preciso obter o número do telefone do usuário lá no fluxo do typebot... |
Positivo. |
|
Please, fix the lint with |
Resolves two upstream regressions confirmed in our forensic data: - evolution-foundation#2132 / PR evolution-foundation#2264: connection shows "Online" but is silently disconnected - evolution-foundation#1910 / PR evolution-foundation#2373: stream errored (ack) on outgoing media kills socket PR evolution-foundation#2151 also lands in rc10, replacing makeMutex with async-mutex — our make-mutex.js timeout patch is now obsolete and archived to patches/_archive/baileys+7.0.0-rc.9-makemutex-timeout.patch.obsolete. Production zombie-instance incident (2026-05-06 21:25 → 23:05+ BRT) tracked to these exact bugs: messages.upsert frozen across heartbeats, dbStatus=open while wsReadyState=null, Stream Errored (ack) on media-class boomData. The reporter on evolution-foundation#2132 also pinned the regression to 7.0.0-rc.9 specifically. Local rc10 verified: container Up healthy, decrypts live messages, all GDW patches (001-008) survive the bump. axios 1.16.0 type drift required 3 single-line `as string` casts on response.headers['content-type'] (whatsapp.baileys.service.ts, chatwoot.service.ts). Also adds posthog-node@^5.21.2 (consumed by src/observability/posthog-router.ts introduced in the previous commit). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
O Typebot não respondia mensagens vindas de JIDs que terminam com "@lid", apenas "@s.whatsapp.net".
O comportamento ocorria porque o número era sempre extraído via: remoteJid.split('@')[0]
Com a atualização do WhatsApp Web, algumas mensagens de mídia chegam com JID "@lid", e nesses casos o JID completo precisa ser mantido.
Ajuste realizado:
ANTES:
number: remoteJid.split('@')[0]
DEPOIS:
number: remoteJid.includes('@lid') ? remoteJid : remoteJid.split('@')[0]
Com essa condição, mensagens vindas de ambos os formatos passam a ser tratadas corretamente pelo Typebot.
📋 Description
🔗 Related Issue
Closes #(issue_number)
🧪 Type of Change
🧪 Testing
📸 Screenshots (if applicable)
✅ Checklist
📝 Additional Notes
Summary by Sourcery
Bug Fixes: