docs: changelog for signal cache flush lock-contention fix (whatsapp-rust#888) - #344
docs: changelog for signal cache flush lock-contention fix (whatsapp-rust#888)#344jlucaso1 wants to merge 2 commits into
Conversation
📝 WalkthroughWalkthroughAdds a changelog entry ( ChangesChangelog: flush_signal_cache read lock fix
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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 |
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
changelog/2026-06-18-flush-signal-cache-readlock.mdx (1)
10-10: ⚡ Quick winSimplify sentence structure to follow the one-idea-per-sentence guideline.
Line 10 combines multiple ideas in single sentences. Per the coding guideline for
**/*.{md,mdx}files, keep sentences concise with one idea per sentence. The second sentence mixes the consequence (blocking) with the cause (lock contention). Breaking these into separate, focused sentences improves clarity.♻️ Proposed refactoring to simplify sentence structure
`flush_signal_cache` runs once per decrypted message and on most outgoing sends. Previously it called `get_device_arc().read()` and held the resulting read guard across the entire `signal_cache.flush(...)` call — a batched SQLite write. Any concurrent `modify_device` or `process_command` (both of which require a Device write lock) would block for the full flush duration, creating read↔write lock contention on the per-message hot path. + `flush_signal_cache` runs once per decrypted message and on most outgoing sends. Previously, it called `get_device_arc().read()` and held the read guard across the entire `signal_cache.flush(...)` call — a batched SQLite write. Any concurrent `modify_device` or `process_command` operations require a Device write lock and would block for the full flush duration. This created read↔write lock contention on the per-message hot path.🤖 Prompt for 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. In `@changelog/2026-06-18-flush-signal-cache-readlock.mdx` at line 10, The second sentence in the diff starting with "Any concurrent" combines multiple ideas (the blocking behavior and the read-write contention consequence) in a single sentence, violating the one-idea-per-sentence guideline for markdown files. Break this sentence into separate, focused sentences by first stating what operations would block and why, then in a separate sentence explaining the consequence of this blocking (the contention on the hot path). Each sentence should address a single concept or idea to improve clarity and readability.Source: Coding guidelines
🤖 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.
Nitpick comments:
In `@changelog/2026-06-18-flush-signal-cache-readlock.mdx`:
- Line 10: The second sentence in the diff starting with "Any concurrent"
combines multiple ideas (the blocking behavior and the read-write contention
consequence) in a single sentence, violating the one-idea-per-sentence guideline
for markdown files. Break this sentence into separate, focused sentences by
first stating what operations would block and why, then in a separate sentence
explaining the consequence of this blocking (the contention on the hot path).
Each sentence should address a single concept or idea to improve clarity and
readability.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: d6fdcdfb-bc3d-4ddc-9e11-1024f22c0f3d
📒 Files selected for processing (2)
changelog/2026-06-18-flush-signal-cache-readlock.mdxdocs.json
1 participant
Summary\n\nAdds a changelog entry for whatsapp-rust#888 — a performance fix that eliminates Device read↔write lock contention on the per-message hot path.\n\nWhat changed in the library:\n
flush_signal_cachepreviously held the Deviceread()guard across the fullsignal_cache.flush(...)call (a batched SQLite write). It now clones thebackendArc fromget_device_snapshot()and drops the guard before flushing, so no device lock is held during I/O. No API or behavior change.\n\n## Files changed\n\n-changelog/2026-06-18-flush-signal-cache-readlock.mdx— new changelog entry\n-docs.json— registers the new page at the top of the Changelog tab\n\n## Test plan\n\n- [ ] Mintlify renders the new changelog page without errors\n- [ ] Entry appears at the top of the Changelog list (above June 15)\n- [ ] No other pages affectedGenerated by Claude Code
Summary by cubic
Adds a changelog entry for
whatsapp-rust#888documenting theflush_signal_cacheperformance fix: clone thebackendArc fromget_device_snapshot()and drop the Device read lock before the batched SQLite write to remove read↔write lock contention. Updatesdocs.jsonto surface the new page at the top of the Changelog and refines the entry wording for clarity.Written for commit c1e5a0c. Summary will update on new commits.
Summary by CodeRabbit
Bug Fixes
Documentation