docs(signal-protocol): document counter-lease waiver opt-out - #475
Conversation
whatsapp-rust#1211 added SessionRecord::waive_counter_lease and SenderKeyRecord::waive_counter_lease, letting a consumer whose own persistence is already synchronous and durable before the wire opt out of the batched counter lease that otherwise burns a full reservation on every component export. Document the API, its trade-off, and the per-record-type failure behavior, and cross-link it from the Record components section it primarily benefits. Ref: oxidezap/whatsapp-rust#1211
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
📝 WalkthroughWalkthroughThe Signal protocol documentation now describes per-record ChangesCounter Lease Documentation
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
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/signal-protocol.mdx | Documents the counter-lease waiver API, its persistence requirements, reservation behavior, failure semantics, and component-store use case. |
Reviews (2): Last reviewed commit: "docs(signal-protocol): split dense lease..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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 `@advanced/signal-protocol.mdx`:
- Line 1334: Update the trusted-reload comparison in the paragraph beginning
“This gives up a real guarantee” to apply only to direct Device stores. Remove
or qualify the claim that synchronous durable persistence before sending is
required, since SignalStoreCache trusted reload relies on a matching live-cache
incarnation and warm sends use write-behind.
- Line 1319: Revise the subsection around the durable snapshot and component
export discussion to address the reader directly with “you” and active voice.
Split dense sentences so policy, persistence, recovery, and export behavior are
each expressed as concise, separate statements, including the text around the
component export explanation and the counter example.
🪄 Autofix
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 Plus
Run ID: 27020d37-e98f-4465-b7b1-10cc0ab2de65
📒 Files selected for processing (1)
advanced/signal-protocol.mdx
SignalStoreCache's trusted reload is a matching live-cache incarnation, not synchronous durability -- its warm sends use the coalesced write-behind. Only a direct Device store's trusted-reload rationale ties to synchronous durability. Corrects an inaccurate comparison flagged by review.
Dismissed because a newer commit was pushed; Greptile will re-review the current head.
![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: 8d34e5b7c9
ℹ️ 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".
AGENTS.md asks for one idea per sentence. Break the run-on covering eligibility, the motivating case, and why into_components() re-burns the reservation into separate sentences.
![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: Documentation-only update to signal-protocol.mdx; no code, API, data, or operational behavior changes. The documented durability tradeoff belongs to the referenced prior code PR, so no human-owned product or architectural decision remains here.
Re-trigger cubic
2 participants
Summary
SessionRecord::waive_counter_lease()andSenderKeyRecord::waive_counter_lease().advanced/signal-protocol.mdx, right after the existing counter-lease/rebase documentation and before Record components — the section describing the component-export use case this API exists for.Errbehavior betweenSessionRecordandSenderKeyRecord.Why
whatsapp-rust#1211 explains that a consumer whose persistence is a component export gets nothing from the batched counter lease (it's already durable before the wire) but previously paid for it anyway —
into_components()had to materialize a full 64-counter reservation on every export, so four consecutive DM sends landed on the wire at counters0, 64, 128, 192instead of0, 1, 2, 3. This is a new public API onwacore-libsignal'sSessionRecord/SenderKeyRecord, so it needed documentation alongside the existing counter-lease writeup inadvanced/signal-protocol.mdx.Test plan
wacore/libsignal/tests/counter_lease.rs/wacore/libsignal/src/protocol/group_cipher.rsfor accuracy (per-type failure behavior, archived-state burn, default-unchanged guarantee).Ref: oxidezap/whatsapp-rust#1211
Generated by Claude Code
Summary by cubic
Documents the counter‑lease waiver opt‑out in
advanced/signal-protocol.mdxforSessionRecord::waive_counter_lease()andSenderKeyRecord::waive_counter_lease().Adds a new “Waiving the counter lease” subsection that explains when to use it, the durability trade‑off, per‑record failure behavior, and that pre‑existing reservations burn once; cross‑links from “Record components”, fixes the
SignalStoreCachetrusted‑reload comparison to call out a live‑cache incarnation (not synchronous durability), and splits a dense sentence per the style guide.Written for commit 4c6c766. Summary will update on new commits.
Summary by CodeRabbit
New Features
Documentation