fix(unread): keep participated threads in the Inbox and persist its evidence across launches by matt2e · Pull Request #1697 · block/buzz-app

matt2e · 2026-10-27T05:45:07Z

This PR is now a draft umbrella, frozen at 34fc40668. It is split for review into three PRs, each stacked on the one before:

fix(unread): keep the viewer's threads in the Inbox under busier channels #2401: per-channel windows and remembered threads, which fix the bug;

feat(unread): restore the Inbox's evidence from a device record on launch #2407: the device record and restore;

perf(unread): catch the Inbox up from a saved mark instead of re-reading every repair #2408: catch-up from a saved mark.

This PR closes when #2408 merges.

Problem

A thread you had replied in vanished from the Inbox (reported in #buzz-team). The Inbox was rebuilt on every launch and check from a single read: the newest 500 messages across all your channels. On a busy roster that reaches back only a few hours. Once busier channels pushed a thread out, nothing brought it back, and a read reply whose root had aged out showed up as a loose row of its own.

reel-pr.mp4

Main 67e404917 is on the left and this branch 9cce1329c on the right. Both run the web app on a fresh device against one local fixture relay with the same made-up team. Playback is 1×, with long waits cut.

What the reel shows

1 · A reply in your thread. Diego answers, without an @mention, in a quiet channel's thread you replied in. 660 newer messages elsewhere push it out of main's read. Only the branch shows the row and the thread dot, at launch and after a reload.
2 · One thread, one row. Three read @mentions sit in a three-day-old thread you replied in. The Inbox lists one row per thread, so the branch's single #incident-review row is correct. Main's three rows are the degraded case. The thread's root and your reply are older than its read, and it never looks up the root of a read reply, so each mention stands alone (the #buzz-team symptom). Main regroups only once the thread is opened.
3 · A quiet channel. A post from nine hours ago, with no @mention, in a channel you last read three days ago. The branch marks the channel unread; main does not until you open it.
4 · A thread from three weeks ago. A new reply in an old thread you replied in, behind 130 newer messages of yours. The branch finds it by paging back through your own messages; main never does.
5b · Relaunch while message reads are held for 15 s. The branch shows the rows it saved on the device at about 0.5 s and keeps them through the read error. Main stays empty, even once the relay answers again.
6 · The once-a-minute check. Both make the same number of queries, but main downloads about 250 kB and the branch about 50 kB. The Inbox does not change. This was recorded before fix(unread): repair unread from the recovery tick only every 15 minutes #2252. Since then, on both builds, a healthy minute check reads nothing of unread; it repairs unread only while a repair is owed or when the 15-minute backstop is due.
7 · Same result on both. A reply older than a channel's "caught up" point, which scrolling to the end on another device leaves. An earlier version of this branch missed it; both show it now.

How it works now

Each channel on its own, plus your threads. Each joined channel is read from its read mark, so a busy channel cannot crowd out a quiet one. The Inbox also remembers the threads you take part in: your replies, found once by paging back through your messages, and mentions, answers and follows. The 50 most recent are read whole; the rest are read only for new replies. The full read also keeps main's newest-500 read, so it holds everything main's read holds.
Evidence saved on the device. The signed events behind the Inbox, the remembered threads and a "caught up to here" mark are saved in IndexedDB (buzz-unread-v1), per relay and viewer. They are re-verified on launch and purged when you leave a community.
Later checks read only what changed. Launch, reconnect and each unread repair the minute recovery check makes read one filter per 128 channels, starting 31 minutes before the mark to catch late commits. The minute check is a recovery hint. Since main's fix(unread): repair unread from the recovery tick only every 15 minutes #2252, which this branch keeps, it repairs unread only while a repair is owed, as after a failed or dropped read, or when the 15-minute healthy backstop is due. Otherwise it reads nothing of unread, on main as on the branch. The full read runs only on a fresh device, from a record that is incomplete (over its cap, for example) or whose mark is over a day old, when a catch-up is still full after six pages, and on Refresh.
Failed reads say so. A read that fails shows "Some recent activity could not be checked" with Refresh, instead of counting zero.

Details and limits are in docs/inbox.md.

Measured

These are medians of 3 runs against the live relay: read-only, one viewer, during a quiet hour. The branch side is this branch's production code, measured as a11a08388. Since then the branch has been rebased onto newer main, which brought #2252 (below), and has taken fixes for review findings. None of that was re-measured.

	main	branch
Each unread repair by the minute check, before #2252	1 request, 481 KB, ~56 ms relay time	1 request, 1–15 KB, 10–16 ms relay time
Warm launch, all `/query`	122 requests, 10.3 MB, 5.6 s relay time	116 requests, 9.4 MB, 5.6 s relay time
First Inbox row, warm launch	7.1 s	6.4 s
Unread CPU per idle minute, 1× / 4× throttle	77 / 246 ms	151 / 685 ms
Inbox rows listed	51	80–82
IndexedDB written per open hour	none	~0.44 MB

Both sides were measured before #2252 (merged 2026-11-03): main as 67e404917, the branch as a11a08388. At that point the minute check repaired unread every minute, so the first row was each minute's read. Those main figures no longer describe main. Since #2252, a healthy minute check on main reads nothing of unread and repairs only while a repair is owed or once 15 minutes have passed since the last repair. The branch keeps that gate. The first row is now the cost of one such repair, as measured then. The idle-CPU and IndexedDB rows come from the same pre-#2252 runs and were not re-measured either.

Known limits

A relaunch with the relay not answering at all. This is scenario 5, which is not in the reel. Like main, the branch shows no saved rows until the relay answers. Saved rows appear early only while channel, profile and read-state reads still answer (5b). Which of those reads they wait on has not been narrowed down.
No runtime kill switch. Nothing is behind a flag. Rollback is a revert and a release.
Over-cap records. If what the Inbox would save is over 2,048 events or 4 MiB, every launch runs the full read and shows no saved rows. In the measured case, with the cap lowered to simulate this, that was ~7 requests and ~3 MB. Within that session, later checks still read only what changed.
Not exercised: the native Tauri host, and live traffic in a busy hour.

For reviewers

src/features/relay/session.ts is FOUNDATION and needs its owner's review. The change (+8/−2) passes the device storage and a roster-settled check to createUnread, and makes the cache clear wait for the saved record to be wiped.
Browser cases: one file added, none removed. tests/browser/unread-storage.spec.mjs has two cases, both needing a real browser: lower layers stub IndexedDB, the reload and the broker's minute check.
- The IndexedDB boundary: a record survives a reload with its mark stored apart, a refused write keeps the last record, a purge clears only its partition, and the purge fence holds across windows.
- A warm relaunch of the built app: the saved rows show before the relay answers, then only the catch-up read is sent, as on a minute check once the 15-minute backstop is due, and a reply deleted meanwhile is dropped.
Each failed on the code before its change; the commits give the details.

🤖 Generated with Claude Code

wesbillman

🤖 Star Lord’s automated source review via Wes’s account.

Three P2 correctness fixes and one P3 keyboard-focus fix are detailed inline. Rocket, Mantis, Groot and integration review are complete.

Head 4d69bfbf85fdf6a1e2ee94c70c6679a21f3b40dc; base b6e1941e6e29f2f688ba8e4920c5aaa175397221. Source only: no tests or app execution. CI was still running in the snapshot; native behavior, real IndexedDB lifecycle and failure-path interactions remain unverified.

kalvinnchau

🤖 Two product regressions and one browser-test ordering defect are detailed inline. The duplicate participation-budget defect is already covered by comment 4387616679 and is not repeated.

[P2] The required profile-preview journey also fails in Chromium and WebKit at this head: tests/fixtures/profiles.tsx:247 returns room evidence for the new per-channel queries, adding an unread badge so the exact button name "One" no longer matches. The failure was reproduced; this fixture/locator explanation is inferred from the fixture and failure snapshot. Update the fixture query handling or locator while retaining the profile-preview assertions.

… split oversized reads Review of 4d69bfb (PR #1697, wesbillman and kalvinnchau): seven inline threads and one failing required browser journey. Participation budget: a full-page thread read's split rereads replies the page already admitted, and they were charged again, so four remembered roots of 200 replies could exhaust the 1,024-reply budget on duplicates and drop a thread. Admitted replies are now tracked by ID across the pass and a full page is judged against the filter's own limit. Overlays at capacity: a peer edit or deletion ranked as unpinned because its `e` reference has no reply marker, so once pinned evidence filled the budget it was silently dropped and the superseded body stayed counted. An edit or deletion now ranks with its newest-ranked content target and is admitted while the target is; when its own target goes first, the target is retired with it. Remembered threads after restart: a remembered thread whose viewer reply is older than both the authored page and the 200-reply thread page lost its membership once its replies were read, since `want()` suppressed the lookup for read replies. Read replies in a remembered thread now run the membership lookup, which recovers the viewer's reply as a verified witness or finds it deleted and lets the thread leave; mention-only threads still gain no membership. Capacity across channels: eviction was oldest-first across every channel, so a busy channel's live traffic could evict a quiet channel's only unread message, which was then rejected as too old on refresh and read as a confident zero. Ordinary evidence is now evicted from the channel holding the most of the exhausted budget (events or bytes), oldest first; pinned evidence still goes last. A channel left with nothing retained loses observed coverage instead of counting zero. Oversized responses: a roster's windows can exceed the reader's 8 MiB response cap (40 channels of 76 messages with 3,000-byte bodies), and the identical retry failed the repair with no Inbox items. A response over the cap now splits the request deterministically — filters in halves, a lone filter's `ids` in halves, a lone filter's limit halved, dropping a filter at limit 1 — and the parts are read next; `READ_BUDGET_EXCEEDED` names the reader's error. Inbox partial notice: keyboard-activating its Refresh removed the focused button with no destination. It now joins the `retryButton` ownership handoff; focus moves to the alert's Retry when the refresh fails and to a stable Inbox control when it succeeds, and stays wherever the person moved it meanwhile. Ownership is only claimed by the ref release, since a control's ref is also released when its props change. Tests: the sidebar-unread journey waits until Alpha's window is held rather than asserting on whichever concurrent batch arrived first; the profiles fixture answers the repair's own filter shapes with nothing, as its former single evidence query did, so "One" carries no badge. Regressions cover each fix, including an owner-through-real-reader run of the oversized-response split. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: Matt Toohey <contact@matttoohey.com>

matt2e · 2026-10-27T11:31:22Z

🤖 Re: the failing profile-preview journey (kalvinnchau's review body) — fixed in 29a55a7 by the fixture: tests/fixtures/profiles.tsx now answers any filter matching isUnreadWindowBatch([filter]) (per-channel windows, authored page, thread reads) with no events, as the former single #h: [one, two] evidence query effectively did, so channel "One" carries no unread badge and the exact-name locator matches. profiles.spec.mjs passes in Chromium and WebKit on this head.

… split oversized reads Review of 4d69bfb (PR #1697, wesbillman and kalvinnchau): seven inline threads and one failing required browser journey. Participation budget: a full-page thread read's split rereads replies the page already admitted, and they were charged again, so four remembered roots of 200 replies could exhaust the 1,024-reply budget on duplicates and drop a thread. Admitted replies are now tracked by ID across the pass and a full page is judged against the filter's own limit. Overlays at capacity: a peer edit or deletion ranked as unpinned because its `e` reference has no reply marker, so once pinned evidence filled the budget it was silently dropped and the superseded body stayed counted. An edit or deletion now ranks with its newest-ranked content target and is admitted while the target is; when its own target goes first, the target is retired with it. Remembered threads after restart: a remembered thread whose viewer reply is older than both the authored page and the 200-reply thread page lost its membership once its replies were read, since `want()` suppressed the lookup for read replies. Read replies in a remembered thread now run the membership lookup, which recovers the viewer's reply as a verified witness or finds it deleted and lets the thread leave; mention-only threads still gain no membership. Capacity across channels: eviction was oldest-first across every channel, so a busy channel's live traffic could evict a quiet channel's only unread message, which was then rejected as too old on refresh and read as a confident zero. Ordinary evidence is now evicted from the channel holding the most of the exhausted budget (events or bytes), oldest first; pinned evidence still goes last. A channel left with nothing retained loses observed coverage instead of counting zero. Oversized responses: a roster's windows can exceed the reader's 8 MiB response cap (40 channels of 76 messages with 3,000-byte bodies), and the identical retry failed the repair with no Inbox items. A response over the cap now splits the request deterministically — filters in halves, a lone filter's `ids` in halves, a lone filter's limit halved, dropping a filter at limit 1 — and the parts are read next; `READ_BUDGET_EXCEEDED` names the reader's error. Inbox partial notice: keyboard-activating its Refresh removed the focused button with no destination. It now joins the `retryButton` ownership handoff; focus moves to the alert's Retry when the refresh fails and to a stable Inbox control when it succeeds, and stays wherever the person moved it meanwhile. Ownership is only claimed by the ref release, since a control's ref is also released when its props change. Tests: the sidebar-unread journey waits until Alpha's window is held rather than asserting on whichever concurrent batch arrived first; the profiles fixture answers the repair's own filter shapes with nothing, as its former single evidence query did, so "One" carries no badge. Regressions cover each fix, including an owner-through-real-reader run of the oversized-response split. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: Matt Toohey <contact@matttoohey.com>

…loader, count only channel cursor pages CI on ffdf357 (PR #1697): the JavaScript shard and two browser journeys. The broker's Vite config reaches `unread-window-batch.ts` through `relay-broker.mjs`, and its extension-less `./events` import drew Vite's `configLoader: 'native'` warning that `vite-config.test.mjs` forbids. The import now names `./events.ts`, as `channel-details-protocol.ts` does. The message-navigation and scroll-paging journeys counted every query with `until` as a channel cursor page. Their fixture history is written by the viewer, so the authored page is full and the walk continues with `until` + `before_id` pages of its own (one and two respectively). Both now count cursor pages by `#h`. Checks: `vite-config.test.mjs` passes; biome and tsc clean; Playwright chromium message-navigation (13) and chromium-measurements scroll cursor paging pass. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: Matt Toohey <contact@matttoohey.com>

kalvinnchau

🤖 Two recovery defects remain at this head; details inline.

wesbillman

🤖 Star Lord’s automated source review via Wes’s account. One additional P2—missing retry feedback after dropped thread reads—is detailed inline.

Source review also corroborates the existing cold-thread disappearance and native size-rejection mismatch; those findings are not duplicated here. The earlier admission, overlay, retention and focus fixes are present.

P3 — Sanitize public review material. The PR description and performance narratives in several commit messages include live workspace channel names and channel/message ID prefixes. Replace those identifiers with generic labels while retaining measurements and legitimate attribution.

Rocket, Mantis, Groot and integration review complete. Head 1cd1136aab64d8b22cb7e8c73df05cd2d9e9f9aa; base 1db9a6ca8294c356b8d845b941af3339e22f1578. Source only: no tests or app execution; native, IndexedDB and failure-path behavior unverified. CI snapshot successful except Windows validation skipped.

… thread read is dropped, state the cold-tier row contract Review of 1cd1136 (PR #1697, kalvinnchau and wesbillman): three P2 threads. Native size cap: the native host reads at most 16 MiB (`read_response`) and rejects before the reader can measure, with the plain string `Relay response is too large` its IPC carries; the repair's `oversized()` knew only the reader's 8 MiB `ReadError`, so a roster whose windows came back over the cap was retried once identically, dropped, and left the Inbox stale with unknown counts. `READ_BUDGET_EXCEEDED` moves to errors.ts beside the other native messages, and `isOversizedResponse()` names both rejections; the repair splits on either. Regression (unread-startup): a 40-channel roster whose 41-filter request the native host rejects splits to 21 + 20 and every channel is observed (pre-fix: `[41, 41]`, stale, as the reviewer's probe found). Dropped thread reads: a dropped `#e`/`ids` read reached `pass.landed` with no result and bypassed `unchecked`, so the repair ended `observed` with no notice while a participated thread's unread reply was missing. A dropped thread read or root fetch now sets `partial` too; its channels' counts stay observed, the Inbox shows the soft notice with Refresh, and a dropped walk page still leaves only the walk's mark for the next repair. The notice reads "Some recent activity could not be checked." since what is missing need not be a channel. The dropped-cold-read regression now asserts `partial: true`, no error, the channel observed, and `partial` cleared by a Refresh that lands the reply. Cold-tier rows after relaunch: a remembered thread outside the 50 hot ones whose replies the viewer has all read is not a row on later launches, since its boundary reply is passed over by ID and the walk resumes from its mark. This is the contract 520f885 chose on measurement (137 warm rows where 52 belong, two extra root-fetch requests), consistent with channel evidence older than its window; docs/inbox.md now says so explicitly — cold threads are rows while they hold a reply the viewer has not read — rather than "stay in the Inbox", and the walk test names it where it asserts the quiet thread absent. Checks (this checkout, load 25–33): `tsc --noEmit` clean; biome clean on the changed files; vitest unread-repair, unread-startup, unread-lookups, unread, reader, thread-participation and InboxPage suites 7 files, 378 tests pass. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: Matt Toohey <contact@matttoohey.com>