feat!: unified LID-PN lookup via get_lid_pn_entry(&Jid) - #487
Conversation
…t `&Jid` BREAKING: `get_phone_number_from_lid` now takes `&Jid` instead of `&str`. Add symmetric `get_lid_from_phone_number(&Jid)` for PN→LID lookup. Using `&Jid` avoids manual string parsing and allocations — the user part is already available as a field.
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughReplaces Changes
Sequence Diagram(s)sequenceDiagram
participant Groups
participant Client
participant LidPnCache
Groups->>Client: get_lid_pn_entry(jid)
alt jid.is_lid()
Client->>LidPnCache: get_entry_by_lid(jid.user)
LidPnCache-->>Client: Option<LidPnEntry>
else jid.is_pn()
Client->>LidPnCache: get_entry_by_phone(jid.user)
LidPnCache-->>Client: Option<LidPnEntry>
else
Client-->>Groups: None
end
Client-->>Groups: Option<LidPnEntry>
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/client/lid_pn.rs`:
- Around line 241-249: The two methods get_phone_number_from_lid and
get_lid_from_phone_number currently assume callers pass the correct JID kind;
add a defensive check at the start of each (e.g., debug_assert or a runtime
check) that verifies the Jid is the expected type and either log a debug/warn
message and return None on mismatch or panic in debug builds; also update the
doc comments for both functions to explicitly state the expected JID type (LID
for get_phone_number_from_lid, phone-number/PN for get_lid_from_phone_number) so
callers know the contract.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 6fd84da1-d4bd-438b-bd15-ebb21dce0c4b
📒 Files selected for processing (2)
src/client/lid_pn.rssrc/features/groups.rs
…id)` Replace `get_phone_number_from_lid` and `get_lid_from_phone_number` with a single `get_lid_pn_entry` that routes by JID type and returns the full `LidPnEntry` (both lid and phone_number in one lookup).
There was a problem hiding this comment.
♻️ Duplicate comments (1)
src/client/lid_pn.rs (1)
244-249:⚠️ Potential issue | 🟠 MajorRestrict lookup routing to PN/LID JIDs only
On Line 247, the fallback branch treats every non-LID JID as PN. That includes
g.us/broadcast/newsletterJIDs, which can incorrectly hitget_entry_by_phone(&jid.user). ReturnNonefor non-user JIDs instead of routing them as PN.Suggested fix
pub async fn get_lid_pn_entry(&self, jid: &Jid) -> Option<LidPnEntry> { if jid.is_lid() { self.lid_pn_cache.get_entry_by_lid(&jid.user).await - } else { + } else if jid.is_pn() { self.lid_pn_cache.get_entry_by_phone(&jid.user).await + } else { + debug!("get_lid_pn_entry called with non-user JID: {}", jid); + None } }#!/bin/bash # Verify current call sites and whether non-user JIDs may flow into get_lid_pn_entry. rg -nP --type=rust -C2 '\bget_lid_pn_entry\s*\(' rg -nP --type=rust -C2 'Jid::(group|newsletter|status_broadcast)\(' rg -nP --type=rust -C2 'test_.*get_lid_pn_entry'🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/client/lid_pn.rs` around lines 244 - 249, The current get_lid_pn_entry routes every non-LID JID to get_entry_by_phone, which wrongly handles group/newsletter/status JIDs; update get_lid_pn_entry so it first ensures the Jid is a user/phone-type JID (e.g., check a predicate like jid.is_user() or jid.is_phone()) and only then call lid_pn_cache.get_entry_by_phone(&jid.user). For non-user JIDs (groups, broadcasts, newsletter, etc.) return None immediately; keep the existing lid branch using jid.is_lid() and lid_pn_cache.get_entry_by_lid(&jid.user).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@src/client/lid_pn.rs`:
- Around line 244-249: The current get_lid_pn_entry routes every non-LID JID to
get_entry_by_phone, which wrongly handles group/newsletter/status JIDs; update
get_lid_pn_entry so it first ensures the Jid is a user/phone-type JID (e.g.,
check a predicate like jid.is_user() or jid.is_phone()) and only then call
lid_pn_cache.get_entry_by_phone(&jid.user). For non-user JIDs (groups,
broadcasts, newsletter, etc.) return None immediately; keep the existing lid
branch using jid.is_lid() and lid_pn_cache.get_entry_by_lid(&jid.user).
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 6c83d65a-6c93-4bf7-8bed-3b394eb29316
📒 Files selected for processing (2)
src/client/lid_pn.rssrc/features/groups.rs
Group, newsletter, and broadcast JIDs should return None instead of hitting the phone-number cache with a non-phone user part.
Summary
get_phone_number_from_lid(&str)withget_lid_pn_entry(&Jid)— one function that routes by JID type (LID or PN) and returns the fullLidPnEntrywith both sides of the mappingjid.userdirectly into the cache lookupBreaking change
get_phone_number_from_lid(&str) -> Option<String>is removed.Migration
Test plan
cargo clippy --all --testspassesSummary by CodeRabbit