Room membership count lies in many different ways. (SYN-307)

[matrixbot]

The membership count reported in Recents doesn't match that in Public Rooms - and can also be out of sync with the size of the membership list and the actual observed current members of a room:

[11:13] [08:35:06] Hi guys ...
[11:13] [08:36:12] Speaking of playing with the api, I'm just now playing with it. I have to newly created rooms, and when querying /publicRooms I get (among others) num_joined_members: 49
[11:13] [08:36:27] Where do these other 48 members come from?
[11:13] [09:24:20] weird
[11:13] [09:24:27] sounds like a bug
[11:13] [09:24:54] perhaps you keep rejoining it as the same user and the count keeps increasing?
[11:13] [09:26:44] seems likely: most of the default clients won't rejoin if it remembers it had already joined, but if you're playing with the API then it is possible that this is a failure case we aren't seeing
[11:13] * M-kegan [09:27:08] still doesn't quite get the rationale behind not treating multiple joins as noops
[11:13] [09:27:29] it's a bug surely?
[11:13] [09:28:09] haven't we already established that the public rooms number of users is way off?
[11:13] [09:32:24] iirc federation needs multiple joins for something. It may be a bug that those are being sent to the client maybe, but I don't know.
[11:13] [09:32:32] and yes, it is way off Tor
[11:13] [09:35:02] Looks like a bug to me, I queried directly after creating the room.
[11:13] [09:47:52] that's even stranger then.

[11:29] hm, my script and angular is now off by one for nicks in this channel :p
[11:29] Counting yourself?
[11:29] better than before, wonder who it is that can't count
[11:29] I am in my script, yes

[12:07] Erik: any inspiration on the room count nightmare?
[12:08] *room member count
[12:28] Not really
[12:28] could be the current_state_events table getting out of sync with the actual state
[12:29] or a table is returning duplicate rows somewhere

etc.

(Imported from https://matrix.org/jira/browse/SYN-307)

(Reported by @ara4n)

[matrixbot]

Jira watchers: @ara4n

[jryans]

This seems to still apply today: The num_joined_members from /publicRooms for the room directory is much larger than the number of members actually displayed in the member list.

[neilisfragile]

related #7041

[KB1RD]

I've been encountering this issue a lot on my homeserver with #matrix-collaboration:matrix.org. Currently, the room directory seems to think that there are 90 accounts in the room (there's 47) and I've seen it go up when there is no join/leave activity. So, I did a bit of testing. It seems an increase in membership count is triggered by display name changes and avatar changes.

[tulir]

Yeah, it's easily and consistently reproducible: make a room, list it in the directory, send a few displayname changes and see the room directory member count increase by the exact number of membership events that were sent.

[erikjohnston]

This will likely be due to a bug in synapse.handler.stats incorrectly handling display name changes and the like. It works by streaming from the current_state_delta_stream and then working out what incremental changes need to be applied to the room_stats_* tables to bring them up to date.

[anoadragon453]

This looks to be due to this simple check which doesn't take into account whether the previous membership state in the room was JOIN:

synapse/synapse/handlers/stats.py

Lines 235 to 236 in 737b4a9

	if membership == Membership.JOIN:
	room_stats_delta["joined_members"] += 1

There is however a check for exactly this a bit lower:

synapse/synapse/handlers/stats.py

Lines 253 to 266 in 737b4a9

	if self.is_mine_id(user_id):
	# this accounts for transitions like leave → ban and so on.
	has_changed_joinedness = (prev_membership == Membership.JOIN) != (
	membership == Membership.JOIN
	)
	if has_changed_joinedness:
	delta = +1 if membership == Membership.JOIN else -1
	user_to_stats_deltas.setdefault(user_id, Counter())[
	"joined_rooms"
	] += delta
	room_stats_delta["local_users_in_room"] += delta

This could likely be refactored a bit to account for join->join transitions.

Edit: has_changed_joinedness isn't quite what we want, which is to simply check for join->join transitions.

[anoadragon453]

#7977 fixes the increasing membership count on profile changes. If further bugs are found that continue to mess up the room membership count, please file them in a new issue.