fix: unify remoteJid filtering using OR with remoteJidAlt #2249
+0
−2
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 guide (collapsed on small PRs)Reviewer's GuideAdjusts WhatsApp Baileys message fetching so remoteJid and remoteJidAlt are handled together via a single OR condition instead of separate filters, ensuring messages can be retrieved regardless of whether the JID is stored in remoteJid or remoteJidAlt. Sequence diagram for unified remoteJid/remoteJidAlt message fetchingsequenceDiagram
actor "Client"
participant "API Server"
participant "BaileysStartupService"
participant "Database"
"Client"->>"API Server": "HTTP request: fetchMessages with keyFilters { remoteJid, remoteJidAlt }"
"API Server"->>"BaileysStartupService": "call fetchMessages(keyFilters)"
"BaileysStartupService"->>"BaileysStartupService": "build where clause with AND conditions (id, fromMe, participant, etc.)"
"BaileysStartupService"->>"BaileysStartupService": "add OR condition for key.remoteJid and key.remoteJidAlt using the same filter value"
"BaileysStartupService"->>"Database": "query messages with combined OR filter on key.remoteJid and key.remoteJidAlt"
"Database"-->>"BaileysStartupService": "return messages matching remoteJid OR remoteJidAlt"
"BaileysStartupService"-->>"API Server": "return unified result set"
"API Server"-->>"Client": "HTTP response with messages from both addressing modes"
Flow diagram for building unified remoteJid/remoteJidAlt filterflowchart TD
A[Start building fetchMessages filters] --> B{Is keyFilters.id defined?}
B -->|"Yes"| C(["Add AND condition: key.path ['id'] equals keyFilters.id"])
B -->|"No"| D[Skip id filter]
C --> E{Is keyFilters.fromMe defined?}
D --> E
E -->|"Yes"| F(["Add AND condition: key.path ['fromMe'] equals keyFilters.fromMe"])
E -->|"No"| G[Skip fromMe filter]
F --> H{Is keyFilters.participant defined?}
G --> H
H -->|"Yes"| I(["Add AND condition: key.path ['participant'] equals keyFilters.participant"])
H -->|"No"| J[Skip participant filter]
I --> K{Is keyFilters.remoteJid or keyFilters.remoteJidAlt defined?}
J --> K
K -->|"Yes"| L(["Add OR condition: (key.path ['remoteJid'] equals value) OR (key.path ['remoteJidAlt'] equals value)"])
K -->|"No"| M[Skip remoteJid/remoteJidAlt filters]
L --> N[Execute database query with constructed AND and OR filters]
M --> N
N --> O[Return messages matching remoteJid OR remoteJidAlt when provided]
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 there - I've reviewed your changes - here's some feedback:
- Consider adding a brief comment near the new OR block explaining why remoteJid is no longer part of the AND filters and is only handled inside OR with remoteJidAlt, so future maintainers understand the changed filtering semantics.
- If neither remoteJid nor remoteJidAlt is provided in keyFilters, it may be cleaner to skip building the OR block entirely (rather than including an OR with only empty conditions) to avoid constructing unnecessarily complex queries.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Consider adding a brief comment near the new OR block explaining why remoteJid is no longer part of the AND filters and is only handled inside OR with remoteJidAlt, so future maintainers understand the changed filtering semantics.
- If neither remoteJid nor remoteJidAlt is provided in keyFilters, it may be cleaner to skip building the OR block entirely (rather than including an OR with only empty conditions) to avoid constructing unnecessarily complex queries.Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Vitordotpy
approved these changes
Dec 4, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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
Quando sincronizamos o nosso whatsapp com o Evolution, as mensagens ficam salvas com o seguinte formato da propriedade 'key':
{
"id": "AC5D7F832B92FA9393B492D9F9B88C20",
"fromMe": true,
"remoteJid": "[email protected]"
}
porém, quando recebemos novas mensagens nos eventos upsert, as mensagens salvas ficam com o seguinte formato:
{
"id": "AC5D7F832B92FA9393B492D9F9B88C20",
"fromMe": true,
"remoteJid": "267628186730669@lid",
"participant": "",
"remoteJidAlt": "[email protected]",
"addressingMode": "lid"
}
Como é possível observar, o remoteJid é salvo com o endereçamento LID e o JID fica na propriedade remoteJidAlt
A alteração proposta pretende corrigir o filtro de busca de mensagens para considerar tanto o remoteJid quando o remoteJidAlt dentro da cláusula OR da função fetchMessages. Atualmente a busca só funciona filtrando por remoteJid ou remoteJidAlt, e não os dois ao mesmo tempo. Por exemplo, se eu quiser filtrar pela requisição abaixo eu não consigo:
{
"where": {
"key": {
"remoteJid": "[email protected]"
"remoteJidAlt": "[email protected]"
}
}
}
Isso busca somente as mensagens com o remoteJid indicado, e não com o remoteJidAlt também.
O objetivo da modificação seria atribuir uma condição OR das duas propriedades: se existir remoteJid OU remoteJidAlt com o valor especificado.
🔗 Related Issue
Closes #(issue_number)
🧪 Type of Change
🧪 Testing
📸 Screenshots (if applicable)
✅ Checklist
📝 Additional Notes
Summary by Sourcery
Bug Fixes: