Files
fusion/packages/dashboard/docs/room-open-performance.md
Fusion (runfusion.ai) e96cb09982 feat(FN-5388): add warm room cache hydration with open diagnostics
Add room open performance diagnostics and warm cache hydration for room switches (FN-5388). The implementation adds a timing instrumentation utility, SWR cache constants, warm-room handoff logic in `useChatRooms`, and a documentation file covering the performance model, accompanied by regression tes

Fusion-Task-Id: FN-5388
2026-05-20 20:27:11 -07:00

2.1 KiB

Room Open Performance (FN-5388)

Architecture overview

Room open flow in the dashboard:

  1. Rooms list hydrates from SWR cache (CHAT_ROOMS) and revalidates from fetchChatRooms.
  2. Active room is resolved from persisted active-room cache.
  3. loadRoomData does a warm-first read of per-room message/member caches, then background revalidation (fetchChatRoomMembers + fetchChatRoomMessages in Promise.all).
  4. SSE continues to update rooms, members, and messages and writes through to cache.

Per-room SWR cache contract

Keys

  • Messages: SWR_CACHE_KEYS.CHAT_ROOM_MESSAGES_PREFIX + <projectId|global>:<roomId>
  • Members: SWR_CACHE_KEYS.CHAT_ROOM_MEMBERS_PREFIX + <projectId|global>:<roomId>

TTL

  • Room warm-open message TTL: SWR_CHAT_ROOM_MAX_AGE_MS = 60_000
  • Members read with SWR_DEFAULT_MAX_AGE_MS

Write points

  • loadRoomData revalidate success writes members + messages.
  • SSE write-through:
    • chat:room:message:added|updated|deleted|messages:cleared
    • chat:room:member:added|removed
  • Post-send transcript refresh writes room-message cache.

Invalidation points

  • clearRoom writes empty message snapshot.
  • chat:room:deleted and deleteRoom write empty message/member snapshots.

Diagnostics

Enable diagnostics by setting:

localStorage.setItem("kb-debug-room-open", "1");

[room-open] debug payload includes roomId, warm flags, totalMs, and per-phase deltas (select, cache-hit, members-fetch, messages-fetch, hydrate, sse-reconnect-refresh, complete).

Ordering invariant

Server room-message API is requested with order: "desc" and returns newest-first. Client render order remains unchanged and cache snapshots intentionally mirror that desc order.

Out of scope

  • Direct-chat (useChat) cache/latency changes
  • ChatView virtualization
  • Scroll restoration changes (FN-5380)
  • Generic dashboard resume/reliability instrumentation (FN-5385/FN-5389)

Follow-up threshold

If hydrate -> complete is consistently >150ms on a 100-message room, file a follow-up task for ChatView virtualization (do not implement virtualization in FN-5388).