perf(read-state): load peer journals without a strict writeback - #1448

Summary

On a BroadcastChannel change notice, each read-state owner refreshed with save((current) => current). That is a strict readwrite transaction: it does a get, validates the journal twice and puts the unchanged record back, in every listening window, for every notice. The peer's save was already durable, so the writeback did no useful work, and the readwrite lock made it contend with the writing window.

Now the notice handler calls load():

• load() reads through a new optional ReadStateStorage.read(). That is one readonly get with the same readJournal validation.
• A missing record (first use, or cleared elsewhere) still goes through save, which creates the journal as before. This is the only case where refresh still writes. Every real change has already been written by the window that made it. readJournal normalization is deterministic, and ready and the next mutation persist it.
• Unchanged: ready, flush's locked reload and every mutation keep their strict readwrite transactions. A corrupt record is still rejected without being replaced.
• Ordering: loads run on the owner's existing queue, so a late load cannot displace later local intent. A disposed owner applies nothing.
• Why read is optional: test fakes that implement only update keep the previous refresh path.

Evidence

Paired base/candidate runs on a dedicated macOS 26.6 host (Apple M4 Pro VM, 6 CPUs, load ≤4). The harness is a Playwright source fixture with real IndexedDB and BroadcastChannel in Chromium and WebKit:

• 12 rounds in alternating order, with a fresh context per case. 816 cases passed, with no signing attempts and no error states.
• The base is the parent main commit. The candidate differs only in this commit; its production blobs are identical to this branch's.

Transactions:

• Peer/listener refreshes: base ran 7,632 strict readwrite transactions with 7,632 puts. The candidate ran 7,632 readonly transactions with 0 puts.
• Writer mutations: identical on both sides, 3,744 strict readwrite.

Medians at reserve 5,000 (365 KB journal). The candidate was lower in 12 of 12 rounds unless noted:

• With a live peer, local commit drops to the one-window level. Different partition keys do not avoid the base contention, because all partitions share one object store.
• At reserve 0 the 20-notice drain is 9.9 → 2.9 ms (Chromium) and 16.5 → 6.0 ms (WebKit).
• Foreground typing in the peer window during matched writes did not change materially. Keydown delay p95 is ≤1 ms on both sides, and frame p95 is unchanged.

Correctness controls:

• Unit tests:

  • A peer load does not write.
  • A missing record still saves.
  • A corrupt record reports an error without being replaced.
  • A held late load can neither displace later local writes nor write back a deleted record.
  • A disposed owner applies nothing.

• Revocation boundary (external diagnostic, 192/192 cases, base and candidate):

  1. A peer refresh is held in the leaving window.
  2. The window runs the departure order from createCommunities: dispose the read owner, then purgeCommunityDeviceState.
  3. The refresh is released behind an owner-queue barrier.
  4. Checks: the owner state is unchanged and nothing is emitted. The IndexedDB record stays absent after release and after a reload. A reopened owner starts empty.

  This covers the disposal/purge boundary, not the membership-removal service end to end.

Checks at this head (on the measurement host with Hermit active, plus hosted CI):

• pnpm check passes.
• vitest run: 708 files and 10,953 tests pass.
• ./bin/node --test tests/integration/*.test.mjs: 224 pass, 2 fail, 3 skipped. Clean base gives the same result.
  • The 2 failures (plugin-cli, plugin-manager-lock) come from their cargo build --locked step.
  • The host's cargo registry mirror lacks the locked webpki-roots 1.0.10.
  • The hosted "Rust and tool integration" job runs the same suite and passes.
• The read-related browser specs (read-reserve, unread, sidebar-unread, thread-unread, inbox-reading, navigation-mute-read) pass 58/58 in Chromium and WebKit.

Limits:

• This is the source fixture, not the native WKWebView host.
• The reserve is synthetic.
• Samples within one context are dependent.
• WebKit's timer resolution is 1 ms.