fix(ws): render_sidebar uses recipient's current enclave, not None (LC-337) #353
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/lc-337-render-sidebar-enclave-aware"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem
render_sidebar(server/src/routes/ws.rs) re-renders a user's whole sidebar as an OOB swap of#sidebarand is the WS render forReadAllChanged(mark-all-read),DmMuteChanged,RoomNotifyPrefsChanged, and the self-targetedRoomMemberAdded/RoomMemberRemovedarms. It calledload_sidebar(state, viewer, None)- the Home / DM-only shape.#sidebarexists on every page, so that OOB swap is not self-limiting. For a recipient currently viewing an enclave it replaced the enclave sidebar (categories + enclave rooms) with the DM-only shape - blanking it until a manual refresh - and renamed the inner navsidebar-nav-{eid}->sidebar-nav, so a followingrender_enclave_sidebar_navOOB fragment could no longer find its target and was dropped.Reproduced live: viewing an enclave and clicking "Mark all as read" delivers a
<aside id="sidebar" hx-swap-oob="outerHTML">DM-only frame that blanks the sidebar. LC-331 fixed only theSidebarCategoriesChangedarm; the otherrender_sidebarcallers were still clobbering enclave viewers.Fix
Track each connection's current enclave from its
enclave:{id}SubscribeTopicframe and pass it torender_sidebar.subscribe_topic enclave:{id}frame: the room page (room/page.html:6), enclave landing (enclave/page.html:11), and settings (enclave/settings.html:10).hx-boost, so each navigation is a full page load and a connection lives for exactly one page view - the tracked enclave is stable for the connection's lifetime, no staleness.handle_socketgains a per-connectioncurrent_enclave: Arc<Mutex<Option<i64>>>; theSubscribeTopichandler sets it when the topic isenclave:{id};render_sidebartakes it and renders the recipient's real context.Rendering is already per-connection, so a user's Home tab renders the Home sidebar and an enclave tab renders that enclave's sidebar with the correct
sidebar-nav-{eid}id.Notes
cur_enclave,Copy) before the awaits so the send-task future staysSend.render_sidebaris a WS send-task render with no integration harness. Verified manually + full suites.Test
just check(clippy standalone + saas + desktop, fmt) clean.just testandjust test-saasboth pass.Closes LC-337.
render_sidebar re-renders a user's whole sidebar as an OOB swap of #sidebar and backs several live events: ReadAllChanged (mark-all-read), DmMuteChanged, RoomNotifyPrefsChanged, and the self-targeted RoomMemberAdded/Removed arms. It called load_sidebar(state, viewer, None), producing the Home / DM-only shape. Because the #sidebar id exists on every page, that OOB swap is not self-limiting: for a recipient currently viewing an enclave it replaced the enclave sidebar (categories + enclave rooms) with the DM-only shape, blanking it until a manual refresh, and renamed the inner nav from sidebar-nav-{eid} to sidebar-nav so a following render_enclave_sidebar_nav fragment could no longer find its target. LC-331 fixed only the SidebarCategoriesChanged arm; these callers were left clobbering enclave viewers. Track each connection's current enclave from its enclave:{id} SubscribeTopic frame (every enclave page - room, landing, settings - sends one; there is no hx-boost, so a connection lives for exactly one page view and the value is stable) and pass it to render_sidebar. Rendering is already per-connection, so each of a user's tabs renders for the page it is actually on: a Home tab gets the Home sidebar, an enclave tab gets that enclave's sidebar with the correct sidebar-nav-{eid} id. #LC-337 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>