Leaving a room doesn't work (if you are owner)

[iduartgomez]

If you create a room and try to leave it, the next time you refresh River it will come back. This is a room with zero members but the owner.

IDK if same happens if you are NOT the owner or there are more than 1 members, but I presume that works.

[Ivvvor]

I've been seeing this for quite a while on one particular test room of mine, but mostly I find you CAN leave an owned room without it coming back in my experience. Still trying to figure out what the trigger is.

[sanity]

Issue Priority Assessment

Generated: 2026-03-12T22:34:43.053147678+00:00
Issue hash: 277b780b

Value Assessment

Leaving still only removes the entry from ROOMS and the current-room pointer plus the delegate’s local storage, as shown in ui/src/components/room_list/edit_room_modal.rs:255-297. There is no contract-level delta or invitation cleanup when the owner clicks “Confirm Leave,” so the room’s contract state still lists the owner as a member. Every time the synchronizer reconnects it fetches that contract and handle_get_response rebuilds a RoomData (inserting/merging it into ROOMS whenever it sees a GET/subscribe response for that owner key; see ui/src/components/app/freenet_api/response_handler/get_response.rs:65-210). As a result the freshly removed room is immediately rehydrated after a refresh, so the bug described in Issue #163 is still present in the current code.

Because the owner is the only person who can create and delete a room, this means anyone who spins up a room for testing or wants to exit it permanently can’t—every refresh brings it back. That’s not a catastrophic outage, but the inability to meaningfully leave (and therefore to declutter the UI or let other people use that contract key) is a clear user-impact regression for the owners of rooms, particularly for the consistent experience of “create → invite → leave” that the app advertises.

Room lifecycle management is core to River’s decentralized chat goals, so this issue has strategic weight: the UI promises safe, permissioned participation, but owners still retain a contract they cannot opt out of, which weakens the guarantee that state changes are intentional and auditable. The issue doesn’t block other work directly—nothing propagates through the rest of the codebase—but it does leave the onboarding/offboarding path incomplete and could complicate future migrations or cleanup steps if owners can’t ever drop a contract gracefully.

There’s no imminent urgency; no calendar dependency or release deadline requires an immediate fix, so it can sit in the backlog until the next sprint that focuses on room management polish.

Cost Assessment

The scenario is still actionable because the current “Confirm Leave” handler only mutates the in-memory signals and then fires save_rooms_to_delegate() (ui/src/components/room_list/edit_room_modal.rs:269 and ui/src/components/app/chat_delegate.rs:238). There’s no hook that makes the delegate stop listing the owner room, so on the next start the response_handler’s delegate GET branch simply deserializes whatever was persisted (ui/src/components/app/freenet_api/response_handler.rs:229) and merges it back into ROOMS, after which it re-registers the owner key in SYNC_INFO and re-subscribes to the contract (ui/src/components/app/freenet_api/response_handler.rs:424). Because the owner’s key is hardwired into the contract, the room reappears every refresh unless we change what gets saved or instruct the synchronizer to forget the owner on purpose, so the issue hasn’t been overtaken by other changes.

Addressing it touches several subsystems: the modal logic, the persistent delegate storage, and the synchronization/subscribe path. You would need to teach the leave flow to either drop the owner room from whatever gets serialized (so save_rooms_to_delegate() writes a different Rooms snapshot) or to record a “left by owner” flag that response_handler/room_synchronizer respect instead of automatically re-registering the owner key. That likely means adding bookkeeping inside ROOMS/CurrentRoom/RoomData (ui/src/room_data.rs) and ensuring SYNC_INFO::register_new_room (ui/src/components/app/sync_info.rs:57) or the RoomSynchronizer loop checks that flag before re-PUTting. You’ll also need to ensure whatever you persist is consistent with the delegate loader to avoid reintroducing the room immediately after a restart.

The implementation is moderately complex because the leave path we’re changing intersects with asynchronous delegate saves and the continuous RoomSynchronizer loop (ui/src/components/app/freenet_api/room_synchronizer.rs). Any fix must be careful to avoid races where an older save_rooms_to_delegate() call writes the room back after the leave handler has already retired it, and it must keep SYNC_INFO/subscriptions in sync so we don’t leave dangling subscribe requests or drop a room that still needs updates. There are also edge cases when the owner leaves a room that still has members (you can’t simply drop the contract, and you have to decide whether the owner should stop receiving updates while others remain).

There are no external dependencies or approvals tied to this change—it’s purely plumbing within the UI, delegate storage, and synchronizer integration—but the risk is that incorrect persistence or SYNC_INFO handling could either leave the room permanently phantom (never re-syncing when it should) or re-trigger the same issue. Testing will therefore require covering both owner and non-owner leave flows, exercising the delegate save/load cycle, and verifying the subscription behavior (Playwright UI flows with example data plus the delegate persistence path, or the e2e test harness if available) to ensure the room stays gone after a restart.

---

Generated by issue-prioritizer

[iduartgomez]

Duplicated: #138