Memory growth in River UI after #242 deploy

[sanity]

Report

Ivvor on Matrix (2026-05-14, post-#242 deploy):

Latest River is going through memory like crazy

Filing as a separate issue from the rotation bug (#245 fixes that one) since the memory behaviour is independent of the secrets back-fill.

What we don't know yet (please update if reproducible)

• Whether it's the browser tab's heap or somewhere else (Freenet node memory? Chat-delegate state?)
• Whether it grows monotonically vs spikes on specific actions (send message, room switch, member set change)
• Whether disabling private rooms / private-room creation makes it go away

Suspects, ordered by likelihood

1. Repeated delegate rotation churn. The fix(delegate): back-fill prior secret versions for newly-joined members #245 fix re-emits encrypted_secrets for newly-joined members at every version; on a long-lived room with many rotations this is O(versions × members) per join. Probably fine, but worth measuring.
2. Chat-delegate state retention. PR feat: move private-room secret rotation into chat delegate (#228 PR 2) #235 added per-room delegate state (signing keys, member set caches, per-version secret cache at secret_keys::secret(room, v)). The per-version secret cache grows unboundedly — there's no GC for old versions.
3. Re-render loops on ROOMS signal mutations. PR feat(ui): re-enable private room creation (#228 Phase 4) #239 added private-room UI surfaces. A signal that fires too eagerly during rotation propagation could trigger render storms.
4. In-room DM state accumulation. PR feat(common): in-room encrypted direct messages between members (#230 Phase 1) #240 added DirectMessagesV1 (currently empty in production since Phase 2 UI is not shipped). The direct_messages: DirectMessagesV1 { messages: [], purges: [] } field appears in every state update; if something is cloning the whole state for each update, the empty vecs get allocated repeatedly. Cheap individually, but accumulation possible.
5. Subscription leak. The EnsureRoomSubscription once-per-session dedup in ui/src/components/app/chat_delegate.rs:162 is per-session, but the underlying subscription on the node side might be leaking handles.

Repro ideas (need Ivvor or a fresh tester)

1. Open River, take a heap snapshot in DevTools.
2. Create a private room, invite a peer (use fix(delegate): back-fill prior secret versions for newly-joined members #245 build).
3. Exchange ~10 messages.
4. Take another heap snapshot.
5. Compare — what objects are growing? Retained size by class?

If easy: a 5-minute screen recording of chrome://process-internals/ showing the tab's RSS over time would tell us a lot.

Relates to

• fix(delegate): remove wasm-bindgen contamination from committed WASM (#241) #242 (this deploy)
• fix(delegate): back-fill prior secret versions for newly-joined members #245 (rotation back-fill — fixes a separate bug from the same report)
• feat: in-room direct-messages UI + riverctl (#230 Phase 2+3) #243 (Phase 2 DM UI — would expand the state surface further, worth de-risking memory first)

[AI-assisted - Claude]

[sanity]

Update from Ivvor's 16:46 report (post-#245 deploy)

Then I left the room and tried to invite as a new member. This looked like it was kinda going through, but then things went weird and River reverted to the previous user. Then memory footprint went over 16GB and everything crashed out

Investigation in progress. Two hypotheses:

H1: Leave-bug compounding (#247)

If the leave action doesn't fully unsubscribe the local node (confirmed in #247), then the user is in a half-left state: locally removed but the node is still subscribed and receiving `UpdateNotification`s. UI handlers ignore notifications for rooms not in `ROOMS.map` — but the rust state cloning + ciborium deserialization still allocates per notification. Combined with the `Subscription timeout check triggered` → `ProcessRooms` loop firing every ~5s, plus a state size of 130KB+ per UpdateResponse summary (observed in Playwright repro on technic at 23:02 UTC, see /tmp/river-repro-invite.log), this could pile up.

Concrete number from repro: 60s headless idle on production River loaded with public Freenet Official room → heap stable at 199MB. So the leak isn't idle-time. Action-triggered.

H2: Back-fill scaling (PR #245)

The #245 fix has the delegate emit back-fill encrypted_secrets at O(rotations × new_members) entries per rotation. For a room with many rotations and a new member joining, that's a lot of state delta. Each AuthorizedEncryptedSecretForMember is ~225 bytes. 100 rotations × 1 new member = ~22.5 KB in the delta — small. But the room state grows by 100 entries; over many joins the state itself can balloon. State is cloned for every UI rerender + every ciborium round-trip in the synchronizer. State 1 MB cloned 100 times in a loop = 100 MB.

Repro setup needed

To reproduce reliably we'd need:

1. A heavily-rotated private room (so state is large)
2. An invite action followed by a leave + re-invite, like Ivvor's sequence
3. Heap snapshot before / during / after

Best done as an in-browser DevTools session with Ian or Ivvor live. The headless Playwright repro on technic shows heap stable when only the Freenet Official Room (public) is loaded.

Mitigation ideas (in priority order)

1. Fix Leave room doesn't stick: legacy-delegate migration re-adds the room on refresh #247 (leave actually unsubscribes + persists) — removes the "ignored UpdateNotification" loop entirely for left rooms.
2. Cap log volume of full state dumps in synchronizer log lines (the `Other response type: ContractResponse(UpdateResponse {...summary: StateSummary([...])` log lines emit the full 130KB state for every notification — that's a major contributor to retained memory if DevTools is open).
3. Stop the `Subscription timeout check` self-trigger loop from re-arming on every `ProcessRooms` (currently each `subscriptions_initiated == true` schedules a 21s timer to fire another ProcessRooms; this never fully quiesces).

[AI-assisted - Claude]