docs: reflect signal store locking changes from whatsapp-rust#1226 - #482
Conversation
SignalProtocolStoreAdapter and SenderKeyAdapter no longer take a read lock on `device` per operation (whatsapp-rust#1226); they hold Arc<PersistenceManager> and call get_device_snapshot() instead.
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
|
Warning Review limit reached
Next review available in: 43 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
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 |
|
| Filename | Overview |
|---|---|
| advanced/state-management.mdx | Updates the RwLock semantics section consistently with the documented snapshot-based state model; no eligible follow-up issue was identified. |
Reviews (2): Last reviewed commit: "docs: precisely describe the write-prefe..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?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: f1e8b4354c
ℹ️ 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".
Codex flagged that "a slow backend round-trip on one Signal operation no longer queues every other Signal operation behind this lock" understated the mechanism: tokio::sync::RwLock allows concurrent readers, so one reader alone can't block another. The cascade in whatsapp-rust#1226 required a writer (process_command) to arrive mid-round-trip and queue behind the held read guard, with later readers then queuing behind that writer. Split into concise sentences per AGENTS.md style guidance.
Dismissed because a newer commit was pushed; Greptile will re-review the current head.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
0 issues found across 1 file (changes from recent commits).
Confidence score: 5/5
- Automated review surfaced no issues in the provided summaries.
- No files require special attention.
Auto-approved: This is a documentation-only update that corrects an outdated factual claim about locking behavior. The diff is visible and shows no code, configuration, or operational changes. No human judgment on product, security, or architecture is needed.
Re-trigger cubic
1 participant
What changed
oxidezap/whatsapp-rust#1226 moved backend I/O and user scans out of the global Signal cache locks. Among other things, it changed
SignalProtocolStoreAdapter::new/SenderKeyAdapter::newto takeArc<PersistenceManager>instead ofArc<RwLock<Device>>— the adapters now callget_device_snapshot()per operation instead of holding a read lock onPersistenceManager's internaldevice(tokio::sync::RwLock<Device>) for the duration of every Signal store call.advanced/state-management.mdx's "RwLock Semantics" section documented the old behavior as a specific, factual claim:That's no longer true — the Signal store adapters are exactly the code that stopped using
get_device_arc()'s read lock. This PR updates that sentence to describe the current locking, and links to whatsapp-rust#1226 for the rationale (avoiding a slow backend round-trip on one Signal operation blocking every other Signal operation behind the same lock).Why
This is a targeted correction, not new documentation: the sentence being edited made a specific claim about which code takes the
deviceread lock, and that claim is now false. No other page in this repo (observability.mdx,metrics.mdx,concepts/storage.mdx, the rest ofsignal-protocol.mdx) makes a claim this PR falsifies — the change is otherwise internal-only (the touched constructors arepub(crate), not part of the public API), so nothing else needed updating.changelog/was intentionally left untouched, per repo convention.Generated by Claude Code
Summary by cubic
Updated the “RwLock Semantics” docs to match whatsapp-rust#1226: the Signal store adapters now hold
Arc<PersistenceManager>and useget_device_snapshot()instead of taking a read lock ondeviceper operation. It also clarifies the write‑preferringtokio::sync::RwLockcascade (a writer arriving mid round‑trip queues behind a held read; later readers then queue behind that writer), and notes thatget_device_arc()still exists for&mut Deviceaccess.Written for commit 526898c. Summary will update on new commits.