feat(chat): add fetchLid endpoint for PN to LID resolution#2483
Open
MrShennawy wants to merge 2 commits intoEvolutionAPI:mainfrom
Open
feat(chat): add fetchLid endpoint for PN to LID resolution#2483MrShennawy wants to merge 2 commits intoEvolutionAPI:mainfrom
MrShennawy wants to merge 2 commits intoEvolutionAPI:mainfrom
Conversation
Contributor
Reviewer's GuideAdds a new Baileys-based service method and HTTP endpoint to resolve a WhatsApp LID from a phone number, including validation and routing wiring. Sequence diagram for the new /fetchLid PN-to-LID resolution flowsequenceDiagram
actor ApiClient
participant ChatRouter
participant DataValidator
participant ChatController
participant WAMonitor
participant WaInstance
participant BaileysStartupService
participant BaileysClient
participant SignalRepository
participant LidMapping
ApiClient->>ChatRouter: POST /fetchLid { number }
ChatRouter->>DataValidator: validate(fetchLidSchema, NumberDto)
DataValidator-->>ChatRouter: validated NumberDto
ChatRouter->>ChatController: fetchLid(InstanceDto, NumberDto)
ChatController->>WAMonitor: waInstances[instanceName]
WAMonitor-->>ChatController: WaInstance
ChatController->>WaInstance: getLid(number)
WaInstance->>BaileysStartupService: getLid(number)
BaileysStartupService->>BaileysStartupService: jid = createJid(number)
alt signalRepository missing
BaileysStartupService-->>WaInstance: { wuid: jid, lid: null }
else signalRepository present
BaileysStartupService->>BaileysClient: client
BaileysClient->>SignalRepository: signalRepository
SignalRepository->>LidMapping: getLIDForPN(jid)
LidMapping-->>SignalRepository: lid or null
SignalRepository-->>BaileysStartupService: lid or null
BaileysStartupService-->>WaInstance: { wuid: jid, lid }
end
WaInstance-->>ChatController: { wuid, lid }
ChatController-->>ChatRouter: { wuid, lid }
ChatRouter-->>ApiClient: 200 OK { wuid, lid }
Updated class diagram for PN-to-LID resolution endpoint and servicesclassDiagram
class ChatRouter {
+post_fetchLid()
}
class ChatController {
+fetchLid(instanceDto: InstanceDto, numberDto: NumberDto) Promise
}
class InstanceDto {
+instanceName: string
}
class NumberDto {
+number: string
}
class WAMonitor {
+waInstances: Map
}
class WaInstance {
+getLid(number: string) Promise
}
class BaileysStartupService {
+getLid(number: string) Promise
+getStatus(number: string) Promise
}
class BaileysClient {
+signalRepository: SignalRepository
}
class SignalRepository {
+lidMapping: LidMapping
}
class LidMapping {
+getLIDForPN(jid: string) Promise
}
class FetchLidSchema {
}
ChatRouter --> ChatController : uses
ChatRouter --> FetchLidSchema : validates_with
ChatController --> InstanceDto : parameter
ChatController --> NumberDto : parameter
ChatController --> WAMonitor : uses
WAMonitor --> WaInstance : waInstances
WaInstance --> BaileysStartupService : delegates_getLid
BaileysStartupService --> BaileysClient : uses
BaileysClient --> SignalRepository : has
SignalRepository --> LidMapping : has
FetchLidSchema --> NumberDto : validates_number
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 - I've found 1 issue, and left some high level feedback:
- In
getLid, thecatchblock silently swallows all errors; consider at least logging or narrowing the caught error types so unexpected failures are visible in monitoring. - The
getLidmethod currently returns an untyped object{ wuid, lid }; defining and reusing a dedicated return type/interface would make the contract clearer and reduce the risk of shape drift across callers. - For
fetchLidSchema, consider reusing or aligning with the existing validation used forNumberDto(e.g., format/pattern, non-empty constraints) so phone number validation is consistent across endpoints.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- In `getLid`, the `catch` block silently swallows all errors; consider at least logging or narrowing the caught error types so unexpected failures are visible in monitoring.
- The `getLid` method currently returns an untyped object `{ wuid, lid }`; defining and reusing a dedicated return type/interface would make the contract clearer and reduce the risk of shape drift across callers.
- For `fetchLidSchema`, consider reusing or aligning with the existing validation used for `NumberDto` (e.g., format/pattern, non-empty constraints) so phone number validation is consistent across endpoints.
## Individual Comments
### Comment 1
<location path="src/api/integrations/channel/whatsapp/whatsapp.baileys.service.ts" line_range="2057-2066" />
<code_context>
}
}
+ public async getLid(number: string) {
+ const jid = createJid(number);
+
+ if (!this.client?.signalRepository) {
+ return { wuid: jid, lid: null };
+ }
+
+ try {
+ const lid = await this.client.signalRepository.lidMapping.getLIDForPN(jid);
+ return { wuid: jid, lid: lid || null };
+ } catch {
+ return { wuid: jid, lid: null };
+ }
</code_context>
<issue_to_address>
**issue (bug_risk):** Swallowing all errors and returning null LID may hide real failures.
This `try { ... } catch { return { wuid: jid, lid: null }; }` makes all failures in `getLIDForPN` (e.g., connectivity or internal errors) look identical to “no LID mapping”. If callers need to distinguish “no mapping” from “lookup failed”, narrow the catch to specific expected errors from `lidMapping`, or at least log unexpected errors before returning `null` so operational issues are visible.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Author
|
I have addressed the first point by adding error logging in the catch block to ensure failures aren't swallowed silently (Commit: fix(pr-feedback): log error when failing to fetch LID for WUID). Regarding the second point (defining a dedicated return type) and the third point (stricter validation in fetchLidSchema), I decided to keep them as is to maintain consistency with the rest of the codebase. Currently, similar methods and schemas in our project don't use dedicated return interfaces or strict pattern validations. I wanted to match the team's existing patterns rather than introducing a new standard in this specific PR. Let me know if you'd still prefer me to update them!" |
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
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
This PR introduces a new endpoint
/fetchLidthat allows retrieving a user'slidusing their phone number.Motivation and Context
I am currently transitioning the system's core logic to rely primarily on
lidrather than phone numbers, aslidhas proven to be more consistent and reliable across various WhatsApp events.However, in certain scenarios (such as specific incoming messages), the system might only receive the phone number. This new endpoint serves as a bridge, allowing us to fetch the corresponding
lidvia Baileys'signalRepository.lidMapping. This ensures that ourlid-based processing remains robust and uninterrupted even when initially provided with just a phone number.Changes Included
getLid(number)inwhatsapp.baileys.service.tsto query the signal repository for the LID.fetchLidmethod inchat.controller.ts.POST /fetchLidroute inchat.router.ts.fetchLidSchemainchat.schema.tsto validate the incomingnumberpayload.Summary by Sourcery
Add a new chat endpoint to resolve a WhatsApp LID from a phone number and expose the corresponding Baileys service method.
New Features: