Follow the library's JID change, and move it and gpui on again - #64
Conversation
`cargo update` on top of #63, plus the one line upstream made stop compiling. - **whatsapp-rust** and its ten satellites: `210bf742` -> `2421037e`. `c.us` is no longer a namespace of its own: it is the other spelling of the phone namespace, and `Server::parse_known` now resolves it to `Server::Pn` so one person cannot become two identities (oxidezap/whatsapp-rust#1371). `Server::Legacy` is gone with it, and the discriminant is left as a gap rather than reused. - **zed** (`gpui`, `gpui_platform` and their satellites): `76b1096c` -> `9785475c`, two commits, neither of which this tree calls. - **gpui-component** did not move; it is already at the tip #63 put it on. `fallback_chat_name` had the carve-out that change removes: it asked `is_pn_family() || server == Server::Legacy`, because a JID parsed out of `12025550144@c.us` used to answer a server that family did not include. It now parses as `Pn`, so the family test alone is the whole question and the second half no longer names anything. Dropping it is the fix rather than a rewrite -- `chat_fallback_hides_internal_lid` already asks a `@c.us` chat for its name and expects the number, so the behaviour this guards is unchanged and tested from both spellings. Verified: `cargo fmt --all -- --check`, `cargo clippy --workspace --all-targets -- -D warnings` and `cargo test --workspace` clean, plus `cargo +nightly check` on `wasm32-unknown-unknown` for `oxidezap-gui` and `oxidezap-session`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017ZQ28Vqpc3pCasXu3Rzzja
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe chat name fallback now applies numeric phone-number names only to PN-family JIDs. Legacy-server JIDs now use ChangesChat name fallback
Estimated code review effort: 1 (Trivial) | ~5 minutes Merge Risk: ⚪ Minimal · up to The update aligns chat fallback naming with the library’s JID parsing change while refreshing dependencies, with the affected behavior covered by existing tests; no actionable merge-blocking risk remains after normal checks and review. Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Title checkExplanation The title references the JID compatibility change and the GPUI dependency update, which are central parts of the pull request. The wording is somewhat informal but remains clear and related to the changes.
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 57d1d7ff57
ℹ️ 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".
| name = "wacore-binary" | ||
| version = "0.7.0" | ||
| source = "git+https://github.com/oxidezap/whatsapp-rust?branch=main#210bf74226a450045064b3f980931e58567e82dc" | ||
| source = "git+https://github.com/oxidezap/whatsapp-rust?branch=main#2421037ef271d36280a30cb1980a423ab5509f86" |
There was a problem hiding this comment.
For databases populated before this upgrade, route_chat_key stored @c.us addresses verbatim because Server::Legacy was not treated as a PN, but the updated parser now turns those rows into Server::Pn while queries such as page_with_unread filter only by the canonical @s.whatsapp.net/LID strings. The chat-list row therefore still appears after parsing, but its existing messages, receipts, reactions, and contact data are missed; subsequent traffic can also create a second PN-keyed row. Add a chat-store migration that merges/rewrites every persisted JID key and reference from @c.us to its canonical PN spelling, including collision handling.
AGENTS.md reference: AGENTS.md:L19-L22
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
The mechanism is real and I checked it rather than taking it: user_chat admits only Server::Pn | Server::Lid, so before this bump 12025550144@c.us fell out of route_chat_key as the wire string verbatim and was filed under …@c.us; after it, the same address parses as Pn, into_non_ad().to_string() renders …@s.whatsapp.net, and a row already sitting under the old spelling is no longer what the new traffic routes to.
What I could not establish is that such rows exist. c.us is not in the binary token dictionary (wacore/binary/src/tokens.json carries s.whatsapp.net and not it), so the compact form the server sends is the canonical one; the paths upstream guarded for it — canonical_user_server, is_self_dm_recipient — are about a to a caller supplies on the send path, not about an inbound address. That leaves a raw JID_PAIR server string or a history-sync conversation.id as the only ways in, and I have no capture of either carrying it.
So this is not something I can fix by reading; it needs a migration and a decision. What it would look like, mirroring 2026-07-24-000000_bare_identity_keys, which folds device-suffixed keys onto the bare identity in exactly this shape: rewrite chats.jid, messages.chat_jid/sender_jid, reactions.chat_jid/sender_jid, contacts.jid and message_receipts.chat_jid/user_jid from …@c.us to …@s.whatsapp.net, with INSERT OR IGNORE into the canonical key first and a delete after, so a peer that already holds both spellings merges rather than colliding on the primary key. It no-ops on every store that never held one.
I have not pushed it: this PR is a lock-file bump plus the one line the removed variant made stop compiling, and a five-table migration is a change of a different kind. Raising it here once, with the patch described, for @jlucaso1 to decide whether it belongs on this branch or its own.
Generated by Claude Code
2 participants
A follow-up to #63:
cargo updateagain, plus the one line upstream made stopcompiling.
The git sources
210bf742→2421037e.c.usisno longer a namespace of its own — it is the other spelling of the phone
namespace, and
Server::parse_knownnow resolves it toServer::Pnso oneperson cannot become two identities (fix(jid): treat the legacy phone-user spelling as one identity whatsapp-rust#1371).
Server::Legacyis gone with it, and its discriminant is left as a gaprather than reused. The other commit measures JID identity and the caches
keyed by it (perf(bench): measure jid identity and the caches keyed by it whatsapp-rust#1370).
gpui,gpui_platformand their satellites):76b1096c→9785475c, two commits, neither of which this tree calls.The one line that had to follow
fallback_chat_namecarried exactly the carve-out that change removes. Itasked
is_pn_family() || server == Server::Legacy, because a JID parsed outof
12025550144@c.usused to answer a server that family did not include. Itnow parses as
Pn, so the family test alone is the whole question and thesecond half names nothing.
Dropping it is the fix rather than a rewrite, and the behaviour is not taken
on trust:
chat_fallback_hides_internal_lidalready builds a chat from12025550144@c.usand expects+12025550144, so both spellings are stillasserted to reach the same name.
Verified
cargo fmt --all -- --check,cargo clippy --workspace --all-targets -- -D warningsandcargo test --workspace(every suite green, that testincluded), plus
cargo +nightly checkonwasm32-unknown-unknownfor bothoxidezap-guiandoxidezap-session.🤖 Generated with Claude Code
https://claude.ai/code/session_017ZQ28Vqpc3pCasXu3Rzzja
Generated by Claude Code
Summary by cubic
Updates
whatsapp-rustandgpuito their latest commits and fixesfallback_chat_nameto match the upstream JID parse change.Upstream now resolves
c.usaddresses to the phone namespace (Server::Pn) and removesServer::Legacy. The old code checked forServer::Legacybecausec.usdidn't match the phone family; that check is no longer needed. The existing testchat_fallback_hides_internal_lidalready covers both@c.usand@s.whatsapp.netspellings, so behavior is unchanged.Written for commit 57d1d7f. Summary will update on new commits.
Summary by CodeRabbit