docs: log unread/read-receipt flakiness bug (investigating)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
2026-07-03 21:49:52 -04:00
parent 4ecc173554
commit b5db617bd2
+4
View File
@@ -62,6 +62,10 @@ Built and gate-green; verify per [LOTUS_TESTING.md](./LOTUS_TESTING.md), then gr
## 🔴 Open — Actionable
### 🐛 Unread/read-receipt flakiness (reported 2026-07, live) — INVESTIGATING
Room unread indicators are **inconsistent**: reading a message sometimes clears the dot, sometimes leaves it stuck, and **sometimes the unread comes back after it was read** (resurrects). This is the same subsystem as the Wave-1 fixes (T1 `markThreadAsRead` root receipt, N1 favicon double-count, N2 dedupe cache, N4 blanket-DELETE) plus the newly-added **Mark as Unread (MSC2867)** `markedUnreadAtom` — a prime suspect for interference. Look closely at: `state/room/roomToUnread.ts` (handleReceipt recompute vs DELETE, RESET triggers), `utils/notifications.ts markAsRead`, `features/room/thread/threadReceipt.ts`, `state/room/markedUnread.ts` (its Receipt listener + the `unread || markedUnread` dot), and `threadIdForReceipt`/unthreaded-receipt handling. Repro: read a message → dot lingers or returns. Planning session.
### 🧨 Encryption / E2EE — ⚠️ EXTREME COMPLEXITY · 🧠 PLANNING SESSION REQUIRED
Observed live in prod 2026-06-30 during a 2-person **Element Call** (E2EE). These span client rust-crypto (`matrix-js-sdk@41.7.0`) ↔ Synapse ↔ EC MatrixRTC E2EE and are **interrelated** — do NOT spot-fix. **Capture first:** run **Settings → Developer Tools → Crypto Diagnostics** during the next affected call + a synapse-side trace before any fix. (Full runbook was in `LOTUS_E2EE_INVESTIGATION.md`, now in git history.) None are caused by the EC fork work.