Skip to content

docs: changelog for msg_secret semaphore fix (whatsapp-rust#832) #306

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jlucaso1 wants to merge 1 commit into from
Closed

docs: changelog for msg_secret semaphore fix (whatsapp-rust#832) #306

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 20 additions & 0 deletions changelog/2026-06-10-msg-secret-semaphore.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
---
title: "June 10, 2026 — Fix: msg_secret reads serialized through db semaphore"
description: "get_msg_secret and get_msg_secret_with_ts now route through with_semaphore, preventing silent decryption failures on in-memory stores when a read races a write."
---

## Bug fixes

**SQLite store: serialize `msg_secret` reads through the db semaphore ([#832](https://github.com/oxidezap/whatsapp-rust/pull/832))**

`get_msg_secret` and `get_msg_secret_with_ts` were dispatched via raw `spawn_blocking`, bypassing the single-permit `db_semaphore` that all write paths (and most other reads) already acquire via `with_semaphore`. On in-memory (`:memory:`) stores a read that overlaps an active write transaction hits the shared-cache table lock and fails with `SQLITE_LOCKED` — an error not covered by `busy_timeout`. Both call sites treat a backend error as a lookup miss, so the failure was silent.

In practice, the write-behind drain introduced in [#831](https://github.com/oxidezap/whatsapp-rust/pull/831) made this race consistently reachable: the detached batch write could race the very next incoming message's secret lookup. The symptom was encrypted reactions and channel comments (added in [#829](https://github.com/oxidezap/whatsapp-rust/pull/829)) arriving undecrypted, with no error logged.

Both methods now go through `with_semaphore`. A read that arrives during a write waits for the permit instead of failing as a phantom miss.

**Affected stores:** in-memory (`:memory:`) SQLite — used by the test suite and any embedded consumer. File-backed stores with WAL mode are not affected (WAL readers do not block on concurrent writers).
Comment on lines +10 to +16

@coderabbitai coderabbitai Bot Jun 10, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion | 🟠 Major | ⚡ Quick win

Rewrite to use active voice and second person per documentation guidelines.

The description uses passive voice and third person, violating the documentation style guidelines. Changelog entries are user-facing documentation and should address the reader directly.

As per coding guidelines, documentation should use active voice and second person ("you"). The guideline text states: "Use active voice and second person ('you') in documentation."

♻️ Suggested rewrite in active voice and second person 
-`get_msg_secret` and `get_msg_secret_with_ts` were dispatched via raw `spawn_blocking`, bypassing the single-permit `db_semaphore` that all write paths (and most other reads) already acquire via `with_semaphore`. On in-memory (`:memory:`) stores a read that overlaps an active write transaction hits the shared-cache table lock and fails with `SQLITE_LOCKED` — an error not covered by `busy_timeout`. Both call sites treat a backend error as a lookup miss, so the failure was silent.
+Previously, if you used `get_msg_secret` or `get_msg_secret_with_ts`, the calls dispatched via raw `spawn_blocking` and bypassed the single-permit `db_semaphore`. Write paths and most other reads already acquire this semaphore via `with_semaphore`. When you run an in-memory (`:memory:`) store and a read overlaps an active write transaction, the read hits the shared-cache table lock. It then fails with `SQLITE_LOCKED` — an error `busy_timeout` does not cover. The call sites treated backend errors as lookup misses, so you saw silent failures.

-In practice, the write-behind drain introduced in [`#831`](https://github.com/oxidezap/whatsapp-rust/pull/831) made this race consistently reachable: the detached batch write could race the very next incoming message's secret lookup. The symptom was encrypted reactions and channel comments (added in [`#829`](https://github.com/oxidezap/whatsapp-rust/pull/829)) arriving undecrypted, with no error logged.
+The write-behind drain from [`#831`](https://github.com/oxidezap/whatsapp-rust/pull/831) made this race consistently reachable. The detached batch write could race your next incoming message's secret lookup. You would see encrypted reactions and channel comments (from [`#829`](https://github.com/oxidezap/whatsapp-rust/pull/829)) arrive undecrypted. No error appeared in your logs.

-Both methods now go through `with_semaphore`. A read that arrives during a write waits for the permit instead of failing as a phantom miss.
+Both methods now route through `with_semaphore`. When your read arrives during a write, it waits for the permit instead of failing as a phantom miss.

-**Affected stores:** in-memory (`:memory:`) SQLite — used by the test suite and any embedded consumer. File-backed stores with WAL mode are not affected (WAL readers do not block on concurrent writers).
+**Affected stores:** This fix applies when you use in-memory (`:memory:`) SQLite — common in test suites and embedded consumers. If you use file-backed stores with WAL mode, you are not affected (WAL readers do not block on concurrent writers).
🤖 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-10-msg-secret-semaphore.mdx` around lines 10 - 16, Rewrite
the changelog entry into active voice and address the reader directly using
second person; clearly state what you changed and why, e.g., "You previously
dispatched get_msg_secret and get_msg_secret_with_ts via raw spawn_blocking,
which bypassed the db_semaphore; this could cause SQLITE_LOCKED on :memory:
stores and silent misses because busy_timeout didn’t apply. You now call those
methods via with_semaphore so reads wait for the single-permit write and avoid
phantom misses. Note the relation to the write-behind drain (`#831`) and symptom
(undecrypted reactions/comments introduced in `#829`), and list affected stores
(in-memory :memory: only; file-backed WAL not affected)."

Source: Coding guidelines


## Breaking changes

None.
1 change: 1 addition & 0 deletions docs.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -138,6 +138,7 @@
"group": "Changelog",
"pages": [
"changelog/overview",
"changelog/2026-06-10-msg-secret-semaphore",
"changelog/2026-06-10-cag-enc-reactions-comments",
"changelog/2026-06-10-hrtb-closures",
"changelog/2026-06-10-server-aware-lookup-probe",
Expand Down