Renaming two rooms in quick succession silently loses the first rename #17

New Issue

2026-09-12T01:50:52-04:00

jared commented

2026-09-12 01:50:52 -04:00

Severity: high · Type: bug · Confidence: high

Location: src/app/features/room-nav/RoomNavItem.tsx:132-157 (handleSave/handleClear), src/app/hooks/useRoomMeta.ts:39-57 (getLocalRoomNamesContent), confirmed against node_modules/matrix-js-sdk/lib/client.js:1313-1368

Problem

The per-room custom-name feature does a plain read-modify-write of the whole io.lotus.room_names account-data blob: getLocalRoomNamesContent(mx) (a synchronous read of mx.store.getAccountData) → merge in the one room's new/cleared name → setAccountData(...). Reading the actual SDK source confirms setAccountDataRaw only PUTs to the server and does not touch the local store; mx.store's copy is updated only when the change is echoed back over /sync, and client.setAccountData() itself awaits that echo before resolving. So getAccountData/getLocalRoomNamesContent stays stale for the whole round-trip. If the user renames room A, then renames room B before A's echo lands (a few hundred ms to a couple seconds — easily done via the sidebar's inline rename dialog), B's write is computed from a snapshot that doesn't yet contain A's new name and overwrites the entire rooms map server-side, permanently discarding A's rename with no error shown. The codebase already has a purpose-built fix for exactly this class of bug — createAccountDataListStore (used by useUserNotes/bookmarks), which serializes writes through one shared in-memory snapshot — but the room-name feature doesn't use it.

How to trigger

Rename two different rooms' local names back-to-back using the pencil/rename option in the sidebar, a few hundred ms to ~1-2s apart.

Suggested fix

Route local room-name reads/writes through createAccountDataListStore (or an equivalent serialized write queue) the same way useUserNotes does, instead of an ad-hoc read-modify-write against the SDK's local cache.

Filed from the September 2026 client audit (branch lotus @ 4bea4895).

**Severity:** high · **Type:** bug · **Confidence:** high **Location:** `src/app/features/room-nav/RoomNavItem.tsx:132-157` (handleSave/handleClear), `src/app/hooks/useRoomMeta.ts:39-57` (getLocalRoomNamesContent), confirmed against `node_modules/matrix-js-sdk/lib/client.js:1313-1368` ### Problem The per-room custom-name feature does a plain read-modify-write of the whole `io.lotus.room_names` account-data blob: `getLocalRoomNamesContent(mx)` (a synchronous read of `mx.store.getAccountData`) → merge in the one room's new/cleared name → `setAccountData(...)`. Reading the actual SDK source confirms `setAccountDataRaw` only PUTs to the server and does **not** touch the local store; `mx.store`'s copy is updated only when the change is echoed back over `/sync`, and `client.setAccountData()` itself `await`s that echo before resolving. So `getAccountData`/`getLocalRoomNamesContent` stays stale for the whole round-trip. If the user renames room A, then renames room B before A's echo lands (a few hundred ms to a couple seconds — easily done via the sidebar's inline rename dialog), B's write is computed from a snapshot that doesn't yet contain A's new name and overwrites the entire `rooms` map server-side, permanently discarding A's rename with no error shown. The codebase already has a purpose-built fix for exactly this class of bug — `createAccountDataListStore` (used by `useUserNotes`/bookmarks), which serializes writes through one shared in-memory snapshot — but the room-name feature doesn't use it. ### How to trigger Rename two different rooms' local names back-to-back using the pencil/rename option in the sidebar, a few hundred ms to ~1-2s apart. ### Suggested fix Route local room-name reads/writes through `createAccountDataListStore` (or an equivalent serialized write queue) the same way `useUserNotes` does, instead of an ad-hoc read-modify-write against the SDK's local cache. --- _Filed from the September 2026 client audit (branch `lotus` @ 4bea4895)._

jared added this to the Audit 2026-09 · High milestone 2026-09-12 01:50:52 -04:00

jared added the bug priority: high area: settings labels 2026-09-12 01:50:52 -04:00

jared self-assigned this 2026-09-12 01:50:52 -04:00

jared referenced this issue

2026-09-12 01:52:08 -04:00

Client audit 2026-09 — tracking index #89

jared referenced this issue from a commit

2026-09-12 14:59:48 -04:00

fix(rooms): serialize per-room rename writes so back-to-back renames survive

jared closed this issue

2026-09-12 14:59:48 -04:00

Sign in to join this conversation.