feat(usync): surface verified business name (verified_name) - #741
Conversation
usync already queries <business><verified_name/></business> but the response was discarded: UserInfo/IsOnWhatsAppResult only exposed is_business: bool. WA Web (WAWebUsyncBusiness businessParser) parses and shows the verified name. Extends VerifiedName::try_from_node to decode the certificate protobuf carried as the node's content bytes (the usync shape has no name/serial attrs; the name lives in VerifiedNameCertificate.Details.verified_name). Attr/child forms still win when present (business-notification path unchanged). Adds verified_name: Option<VerifiedName> to UserInfo and IsOnWhatsAppResult, parsed from <business><verified_name> in both usync parse paths, and re-exports VerifiedName. Verified: clippy --all-targets -- -D warnings clean; wacore tests green (cert-decode and attr-precedence covered).
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughSummary by CodeRabbit
WalkthroughAdds protobuf certificate decoding for VerifiedName, exposes VerifiedName through feature and crate re-exports, and propagates parsed verified_name into usync user result structs (IsOnWhatsAppResult and UserInfo). ChangesVerifiedName Certificate Parsing and Usync Propagation
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 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 |
Benchmark Results67 unchanged benchmark(s)
|
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/features/mod.rs`:
- Line 31: The public API is missing the VerifiedName re-export; update the
crate root's pub re-exports to include VerifiedName by adding it to the existing
pub use features::{...} list so consumers can access VerifiedName (i.e., ensure
the pub use that re-exports types from the features module includes VerifiedName
alongside the other items).
🪄 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: Repository UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: ff95f729-fbeb-4e23-b2ab-86d1d9f0a736
📒 Files selected for processing (4)
src/features/contacts.rssrc/features/mod.rswacore/src/iq/usync.rswacore/src/stanza/business.rs
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 166bb16fa7
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| user_node | ||
| .get_optional_child("business") | ||
| .and_then(|business| business.get_optional_child("verified_name")) | ||
| .and_then(|vn| VerifiedName::try_from_node(vn).ok()) |
There was a problem hiding this comment.
Skip empty verified-name nodes
When usync returns a per-user <business><verified_name><error .../></verified_name></business> or an empty marker for a business account without a verified-name cert, try_from_node still returns Ok(VerifiedName { name: None, serial: None, certificate: None }) because it never treats error/empty nodes as absent. Both public result types then expose verified_name: Some(...), so callers using is_some() to decide whether a verified business name exists get a false positive; this should mirror the status/picture parsers and return None unless the node actually carries a usable attr/name/certificate and has no error child.
Useful? React with 👍 / 👎.
… verified_name Review follow-up: - VerifiedName is now re-exported in src/lib.rs (not only features/mod.rs), so the type returned by UserInfo/IsOnWhatsAppResult is actually reachable. - parse_verified_name returns None when <verified_name> has an <error> child or is an empty marker (no name, no cert), mirroring the status/picture parsers, so verified_name.is_some() means a real verified name was returned (no false positive for business accounts without a cert).
|
Docs PR opened: oxidezap/whatsapp-rust-docs#276 Documented the new verified_name field on IsOnWhatsAppResult and UserInfo, exposing decoded verified business names from contact lookups. |
What
usync already queries
<business><verified_name/></business>, but the response was thrown away:UserInfoandIsOnWhatsAppResultonly exposedis_business: bool. WA Web (WAWebUsyncBusinessbusinessParser) parses and displays the verified name, so the most useful part of the business query never reached consumers.Changes
VerifiedName::try_from_nodenow decodes the certificate protobuf carried as the node's content bytes. The usync<verified_name>shape has noname/serialattrs; the name lives only insideVerifiedNameCertificate.Details.verified_name. The attr/<name>forms still take precedence when present, so the business-notification path is unchanged.verified_name: Option<VerifiedName>added toUserInfoandIsOnWhatsAppResult, parsed from<business><verified_name>in both usync parse paths (parse_user_common_fieldsandIsOnWhatsAppSpec::parse_response).VerifiedNamere-exported from the contacts feature.Verification
cargo clippy --all-targets -- -D warningscleancargo test -p wacoregreen (certificate decode + attr-precedence covered)Resolves gap-analysis features-05. Breaking (adds a struct field), acceptable pre-1.0.