Delegate-cached room snapshot can be near-empty, not merely stale, and the 5-minute debounce does not explain it

[sanity]

Problem

During a delegate-migration rehearsal on 2026-08-12, a room restored from the chat delegate rendered with one member and no messages, while the predecessor generation still held the full state (2 members, 5 messages, verified directly against the fixture node before the run).

The room slot in the delegate is a debounced cache of room_state (RoomData.room_state, persisted at room_data.rs:200). The debounce is ROOM_SNAPSHOT_MIN_INTERVAL_MS = 5 minutes (chat_delegate.rs:4677). That explains a snapshot being stale by up to five minutes. It does not explain one that is nearly empty.

Something else emptied it, and that is unexplained.

Why this is worth its own investigation

This surfaced while diagnosing #621 (the backward probe cannot fire for delegate-restored rooms, because a PUT of this cached snapshot precedes the migration GET and suppresses the probe's trigger). The two are separate defects:

• Backward probe cannot fire for delegate-restored rooms: a pre-GET PUT of the cached snapshot suppresses its trigger #621 explains why the stale snapshot is never repaired by the probe.
• This issue asks why the snapshot was thin in the first place.

The interaction is what makes it worth attention. A full-but-stale snapshot pushed forward would have looked almost correct to a user, and #621 could have stayed hidden for several more releases. The near-emptiness is what made the symptom loud enough to investigate. If the emptiness has an independent cause, it may be producing quieter damage elsewhere.

Evidence available

• room_synchronizer.rs:1504: No new messages detected for room MemberId(LZS6FCWR) (old_ids: 0, post-merge: 0) — confirms local state held zero messages before the merge, but says nothing about why.
• Delegate slot ciphertext sizes at baseline: public room 1293 bytes, private room 2150 bytes, rooms_meta 134 bytes. The slots are encrypted under the node-local KEK, so contents could not be decoded directly.
• Timing, offered as data and not as an explanation: seeded activity spanned 20:20:32 to 20:21:24, and the fixture snapshot was taken around 20:26, roughly five minutes after the last write. Whether the debounce deferred those writes, whether a teardown flush ran, and whether either relates to the emptiness are all unknown.

Questions to answer

1. What writes room_state into the delegate slot, and under what conditions can it write a state with no messages when messages exist in memory or on the contract?
2. Does a teardown or page-unload path flush the pending snapshot? If not, what happens to writes deferred by the debounce when the page closes?
3. Can a room be persisted before its first contract sync completes, so the cached snapshot reflects a pre-sync state?
4. Is the 5-minute debounce ever bypassed for a first write, and should it be?

Explicitly not assumed

No cause is proposed here on purpose. The rehearsal that found it did not have evidence to decide, and attaching a plausible-sounding guess to it would make it less likely that someone measures it.

Related

• Backward probe cannot fire for delegate-restored rooms: a pre-GET PUT of the cached snapshot suppresses its trigger #621 — the probe cannot fire for delegate-restored rooms (why the thin snapshot is never repaired)
• Backward probe treats a legacy generation's silence as its absence (can adopt an older generation, or seal a false 'nothing to recover') #619 — the probe treats silence as absence

[AI-assisted - Claude]

[sanity]

Issue Priority Assessment

Generated: 2026-08-14T01:21:52.354685017+00:00
Issue hash: d96f219c

Value Assessment

Assessment of Issue #622

Relevance: Still relevant, code has just moved. The debounce mechanism (ROOM_SNAPSHOT_MIN_INTERVAL_MS, 5 minutes) exists exactly as described, though the actual write logic (save_rooms_to_delegate/flush_rooms_to_delegate) lives in ui/src/components/app/chat_delegate.rs rather than the delegate crate path cited in the issue (a labeling slip, not evidence of staleness — the constant itself moved from ~line 4677 to ~4328 due to unrelated edits since PR #534). Nothing in the git history since that PR addresses snapshot emptiness or a first-write bypass, so the core question the issue raises — how a cached snapshot can be nearly empty rather than merely stale — remains genuinely unanswered in the code. One partial finding not in the original issue: there IS a teardown flush (flush_rooms_to_delegate on visibilitychange, per #533), but no beforeunload/pagehide handler, so a hard crash or an unusual platform that skips visibilitychange could still strand a debounced write mid-flight — a plausible but unconfirmed contributor.

User impact: Likely narrow in isolation — it requires the delegate-restore path (used during a WASM migration or app restart-from-cache) to have captured a snapshot from a window where the room had far less state than reality. But per the issue's own framing, its real weight comes from its interaction with #621: an emptied snapshot that never self-repairs (because #621's PUT-before-GET ordering suppresses the backward probe) means an affected user could be stuck seeing a hollowed-out room indefinitely, not just briefly stale. My review confirms #621 is unaddressed in current code, so that compounding risk is live, not hypothetical.

Strategic alignment: Squarely on the "don't lose user data across delegate WASM changes" theme that dominates this repo's migration tooling (legacy_delegates.toml, the whole migration-rehearsal discipline in AGENTS.md). Data-loss-adjacent bugs in the delegate cache are exactly the class of defect this project has been repeatedly burned by (see the WASM-safety and delegate-migration rule files), so this fits the project's demonstrated priorities well.

Blocking factor: Not blocking other work directly, but it blocks confident closure of #621 — fixing #621's probe-ordering bug without knowing why the snapshot was thin risks "fixing" the repair path while leaving the root corruption cause active, so a full fix likely wants this investigated first or alongside.

Urgency: Moderate, not acute. It was caught in a migration rehearsal, not live production, and no user reports are cited. But since it was found by deliberately re-testing the migration path — precisely the practice this repo's AGENTS.md mandates before any delegate/contract WASM change — leaving it open increases the risk that the next real WASM migration (which happens routinely here) silently manifests this for real users. Worth scheduling before the next delegate-WASM-changing release, not urgent same-week.

Cost Assessment

Cost Assessment: Issue #622

Relevance. The issue's diagnosis is directionally accurate but its file references have drifted: ROOM_SNAPSHOT_MIN_INTERVAL_MS and the delegate save/flush machinery live in ui/src/components/app/chat_delegate.rs (not delegates/chat-delegate/src/chat_delegate.rs, which doesn't exist in this repo), and RoomData.room_state is at ui/src/room_data.rs:198, not 200. The "No new messages detected" log line at room_synchronizer.rs:1505 checks out closely. None of this invalidates the issue — it's still an open, unexplained defect — but whoever picks it up needs to re-orient before starting, which is a small but real tax.

Scope and complexity. This is not a "add a bypass here" fix — it's an unscoped investigation into a race between three subsystems: the debounced save path (save_rooms_to_delegate / do_save_rooms_to_delegate / flush_rooms_to_delegate in chat_delegate.rs, a dense 7300+ line file), the room-state merge/sync logic (room_synchronizer.rs), and possibly the visibility/unload flush (document_title.rs, which already registers a visibilitychange listener calling flush_rooms_to_delegate() — so a naive "add a teardown flush" fix may already be moot). The issue explicitly declines to propose a root cause, which is appropriate epistemically but means the real cost is diagnostic, not just coding: someone has to determine whether a room can be persisted before first contract sync completes, whether the debounce is bypassed correctly on first write, and reconcile that against the existing flush-on-hide path. That's a multi-file, cross-subsystem race hunt, the hardest category of bug to bound in advance.

External dependencies. None — pure in-repo investigation and code change, no third-party services, keys, or approvals needed.

Risk. Moderate-to-high if a fix touches the debounce/flush logic, since chat_delegate.rs already carries scar tissue from prior related fixes (issues #533, #420, #397 referenced in comments) and any change to save timing risks reintroducing one of those. The coupling with #621 (the backward-probe suppression) raises the risk of scope creep or of a fix here interacting with the still-open #621/#619 machinery.

Testing effort. There's a solid existing harness — over 100 unit/wasm-bindgen tests in chat_delegate.rs, including dedicated debounce-boundary and coalesce_save race tests — so infrastructure to extend exists. But since the bug is timing-dependent (save-vs-sync-completion ordering), a real regression test likely requires synthetically constructing the race (e.g., firing a save before a mocked sync completes) rather than a straightforward assertion, adding non-trivial design effort on top of the fix itself.

Overall: this is a medium-high cost issue — likely 1-2 days of investigation alone before a fix can even be scoped, given no hypothesis is proposed, three subsystems are in play, and it's explicitly entangled with two other open issues (#621, #619).

---

Generated by issue-prioritizer