dendrite icon indicating copy to clipboard operation
dendrite copied to clipboard

Spaces Summary not working properly over federation

Open boogewooge opened this issue 2 years ago • 5 comments

Background information

  • Dendrite version: 0.8.4
  • Monolith or Polylith?: Monolith
  • SQLite3 or Postgres?: Postgres
  • Running in Docker?: No
  • go version: go1.17.10 linux/amd64
  • Client used (if applicable): Element Web/Desktop

Description

  • What is the problem: Over federation, users can only see rooms they're already in in the space summary, instead of the full list. This is with the non-listed rooms being public.
  • Who is affected: Users on external homeservers
  • How is this bug manifesting: From the logs on my Synapse 1.59.1 instance trying to fetch the room summary on my dendrite instance:
Request failed: GET matrix://my.dendrite.instance/_matrix/federation/v1/hierarchy/%21[REDACTED]%3Amy.dendrite.instance?suggested_only=true: HttpResponseException('404: Not Found')
  • When did this first appear: The first time a user on a synapse instance tried to see a space summary based on my dendrite instance in element.

Steps to reproduce

  1. Create a space on a dendrite instance and add public rooms to it.
  2. Invite a user on a synapse instance to the space and optionally one of the rooms in the space
  3. The synapse-based user will only be able to see any rooms they're already in in the space summary, instead of all (public) rooms in it.

boogewooge avatar May 30 '22 11:05 boogewooge

I also consistently see this issue on 2 instances of 0.8.6, I think it has existed for as long as spaces summary has been working.

When a dendrite has no users in a room it tries to get summary information from the other dendrite (the one that owns the namespace and is still in the room) which fails with a similar error to the synapse one above:
level=warning msg="failed to call MSC2946Spaces on server xa.org.au" error="contents=[123 34 101 114 114 99 111 100 101 34 58 34 77 95 78 79 84 95 70 79 85 78 68 34 44 34 101 114 114 111 114 34 58 34 114 111 111 109 32 105 115 32 117 110 107 110 111 119 110 47 102 111 114 98 105 100 100 101 110 34 125] msg=Failed to GET JSON (hostname \"xa.org.au\" path \"/_matrix/federation/unstable/org.matrix.msc2946/hierarchy/!T1Q7bEvMDxbyvRDm:xa.org.au\") code=404 wrapped=M_NOT_FOUND: room is unknown/forbidden" req.id=oAFi4cqBYh6y req.method=GET req.path="/_matrix/client/v1/rooms/!P0hFeHphHR4Wmpkn:xa.org.au/hierarchy" user_id="@bones_was_here:xonotic.org"

bones-was-here avatar May 30 '22 12:05 bones-was-here

Here's a workaround for (only) the case of a remote homeserver joining a space while not already participating in the room(s) listed in that space.
If the "via": [] array in a m.space.child event lists only Dendrite homeserver(s) (regardless of whether those Dendrites are participating in the space or the room the event points to), the user(s) of the remote homeserver will not see that room in the space summary.
If a Synapse homeserver which is already participating is added to the "via": [] array, then the user(s) of the remote homeserver will see that room in the space summary (even if the remote homeserver is a Dendrite).

It's not ideal because it can be quite slow (if the Dendrite is tried first and then the Synapse? or maybe it's just slow because I used matrix.org) but it's better than people seeing a blank room list when they're the first person to join from their homeserver.

This also may explain why some people have not been able to reproduce the issue: they have a Synapse listed in their m.space.child event(s).

bones-was-here avatar Jul 06 '22 08:07 bones-was-here

This appears to have been fixed by #2578 in 0.9.2

bones-was-here avatar Aug 13 '22 09:08 bones-was-here

still seeing this on 0.9.3 with "join_rule": "restricted"

edit: added a public room to the space, remote server (synapse) still cannot see the room in the space without joining it. adding a different remote server that's in the room to the "via" array fixes visibility.

ashkitten avatar Aug 16 '22 18:08 ashkitten

I believe this is still happening in v0.12. Still getting the same message in the logs.

viviicat avatar Apr 25 '23 02:04 viviicat