docs: reflect atomic newer-wins store_received_tc_token - #380
Conversation
…t#980) whatsapp-rust#980 moved the tc-token newer-wins rule from a Client-level tc_token_lock + get-then-store in history-sync into the store itself (atomic in SqliteStore and InMemoryBackend), closing a cross-source race with the privacy-notification path. Update the ProtocolStore trait docs and the TC Token guide to describe the new atomicity guarantee instead of the removed lock-based monotonicity guard.
|
Warning Review limit reached
Next review available in: 38 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. 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 (3)
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 |
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
No issues found across 3 files
Confidence score: 5/5
- Automated review surfaced no issues in the provided summaries.
- No files require special attention.
Auto-approved: Documentation-only updates to reflect atomic newer-wins semantics for tc-token storage. Minor rewording and annotations in sequence diagrams and comments.
Re-trigger cubic
|
| Filename | Overview |
|---|---|
| api/store.mdx | Adds newer-wins semantics detail to store_received_tc_token doc comment and expands the Note to warn custom-backend authors about the atomic-upsert requirement; no content issues found. |
| api/tctoken.mdx | Rewrites step 3 with unambiguous pre-filter wording, adds a cross-source race explanation paragraph, and updates sequence diagram annotation; documentation is accurate and internally consistent. |
| concepts/storage.mdx | Brief trait-summary comment updated to reflect newer-wins semantics and atomic backend enforcement; change is correct and consistent with the other two files. |
Sequence Diagram
%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
participant HS as History-Sync
participant PN as Privacy-Notification
participant Store as Store (SqliteStore / InMemoryBackend)
Note over HS,PN: Cross-source race (now closed at store layer)
HS->>Store: store_received_tc_token(jid, token_A, ts_A)
PN->>Store: store_received_tc_token(jid, token_B, ts_B)
Note over Store: Atomic newer-wins check inside each call
Store-->>HS: "write-through if ts_A >= stored OR existing is placeholder"
Store-->>PN: "write-through if ts_B >= stored OR existing is placeholder"
Note over Store: No external lock required — both callers converge on the same atomic upsert
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
participant HS as History-Sync
participant PN as Privacy-Notification
participant Store as Store (SqliteStore / InMemoryBackend)
Note over HS,PN: Cross-source race (now closed at store layer)
HS->>Store: store_received_tc_token(jid, token_A, ts_A)
PN->>Store: store_received_tc_token(jid, token_B, ts_B)
Note over Store: Atomic newer-wins check inside each call
Store-->>HS: "write-through if ts_A >= stored OR existing is placeholder"
Store-->>PN: "write-through if ts_B >= stored OR existing is placeholder"
Note over Store: No external lock required — both callers converge on the same atomic upsert
Reviews (2): Last reviewed commit: "docs: clarify tc-token pre-filter wordin..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
"doesn't gate a presence re-subscribe on a newer real token" read as the opposite of the intended behavior. A stale incoming token actually skips both storage and the re-subscribe entirely.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
0 issues found across 1 file (changes from recent commits).
Auto-approved: Documentation-only changes across three .mdx files updating doc comments on tc-token newer-wins semantics, with no logic or source code changes. Low risk and safe to auto-approve.
Re-trigger cubic
2 participants
Summary
Follow-up docs update for oxidezap/whatsapp-rust#980, which:
Client-leveltc_token_lock(which only serialized history-sync chunks against each other) and intostore_received_tc_tokenitself, enforced atomically by each built-in backend (SqliteStorevia anIMMEDIATEtransaction,InMemoryBackendunder its state lock).Changes
api/store.mdx— updated thestore_received_tc_tokendoc comment to describe the newer-wins contract (byte-less placeholder ortoken_timestamp >= existingwrites through, otherwise a no-op) and how the built-in backends enforce it atomically; updated the surrounding<Note>to warn custom-backend authors that a non-atomic override can still race two callers.api/tctoken.mdx— reworded the "Incoming token notifications" steps (the privacy-notification path's own check is now a pre-filter for the presence re-subscribe, not the sole overwrite guard), added a paragraph pointing to the store-level newer-wins as what actually closes the cross-source race, and updated the sequence diagram's annotation onstore_received_tc_token.concepts/storage.mdx— updated the trait-summary comment forstore_received_tc_tokento mention the newer-wins semantics.No changelog entries were added per instructions.
🤖 Generated with Claude Code
https://claude.ai/code/session_01SxXWf7FV4PyphPKMQ4p9gD
Generated by Claude Code
Summary by cubic
Update docs to reflect atomic newer-wins enforcement in
store_received_tc_token, closing the race between history-sync and privacy notifications. Clarifies that the notification pre-filter skips both storage and presence re-subscribe for stale tokens, updates the sequence diagram, and warns custom backends to use atomic upserts.store_received_tc_tokenandtouch_tc_token_sender_timestampas atomic upserts that enforce newer-wins.Written for commit 9754b3d. Summary will update on new commits.