A community learned from another device kept its token as the title

[mpretty-cyro]

A community that reaches a device by config sync shows its raw room token as the conversation title, permanently.

What the user sees

Join a community on one device. On every other device the user owns, the conversation is titled qa-0797141d-423a-484e-801f-d0fc7737b48a-w0-1 instead of its name. The device that joined shows the name correctly. Messages sync fine — only the title is wrong, and nothing the user can do in the app changes it.

This is not limited to freshly created test rooms. PySOGS's own tests assert that a room created with a name has info_updates == 0 (tests/test_rooms.py:86-101); only a later metadata edit moves it to 1. So any community whose metadata has not been edited since it was created — the normal state of a small community — reproduces this.

Why

The community's name is not part of the synced config record. The record carries base URL, room token and pubkey; the name is fetched from the SOGS by each device and stored locally, and the title is roomInfo?.details?.name ?: room (RecipientNames.kt:22).

The joining device fetches it: OpenGroupManager.add() calls the room-details API before writing the community into config. A device that learns of the community from that config can never reach that fetch — add() short-circuits on alreadyJoined, and the config arriving is how it learned about the community at all.

That leaves the poller, which is gated:

OpenGroupPoller.kt:120   val infoUpdates = latestRoomPollInfo?.details?.infoUpdates ?: 0
PySOGS rooms.py:856      if room.info_updates != info_updated:
                             result['details'] = get_room_info(room)

With nothing cached the device sends 0; the room is also at 0; the server reports no change; the poll writes a row with no details; the device keeps sending 0. Forever, and unaffected by time or by opening the conversation.

The change

While the poller has no usable name for a room, ask for the room outright instead of polling it. One branch, at the point that already knows what it has cached.

The predicate is "no usable name", not "no row" and not "no details object" — neither of those can express this state:

• patchRoomInfo is an unconditional INSERT OR REPLACE, so a row exists after the first poll whether details came back or not. A row check fires once and then goes quiet, leaving every already-affected device stuck.
• RoomInfo.details is non-nullable with an empty default (OpenGroupApi.kt:102), so a details-less response deserialises to a present-but-blank object. A details == null check compiles, reads as if it does something, and never fires.

It also matches the render: a blank name is exactly the state that falls back to the token, so the refetch condition and the visible symptom are the same condition. It repairs devices already holding a nameless record, and stops permanently once a name arrives. A failed request never reaches patchRoomInfo, so nothing is written and the next poll retries.

Verification

Join community test @android passes twice at 28s, against a 148s timeout before. Confirmed against a build grepped for the change. The room's counter was read directly from the SOGS database mid-run to confirm info_updates=0 on a room created with its name.

No unit test. There is no existing test harness for OpenGroupPoller or CommunityDatabase, and the change is one predicate inside a poll loop needing the API executor, config factory, database and a server. The Appium spec is what covers it.

For comparison

iOS has the same gate in its poller and would hit the same dead end; it never depends on it, because a community arriving from config triggers performInitialRequestsAfterAdd, which does a full room fetch (LibSession+UserGroups.swift:73-94). That is fire-and-forget (Task.detached + try?), so an iOS device whose fetch fails is stuck exactly as Android was, with no retry. This fix retries until a name arrives.