Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spaces Summary not working properly over federation #2504

Closed
boogewooge opened this issue May 30, 2022 · 5 comments · Fixed by #3347
Closed

Spaces Summary not working properly over federation #2504

boogewooge opened this issue May 30, 2022 · 5 comments · Fixed by #3347
Labels
F-Spaces T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues.

Comments

@boogewooge
Copy link

boogewooge commented May 30, 2022

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.
@bones-was-here
Copy link

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
Copy link

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
Copy link

This appears to have been fixed by #2578 in 0.9.2

@ashkitten
Copy link
Contributor

ashkitten commented Aug 16, 2022

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.

@kegsay kegsay added T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues. F-Spaces and removed bug labels Dec 5, 2022
@viviicat
Copy link

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

S7evinK added a commit that referenced this issue Mar 28, 2024
Fixes #2504

 A few issues with the previous iteration:
- We never returned `inaccessible_children`, which (if I read the code
correctly), made Synapse raise an error and thus not returning the
requested rooms
- For restricted rooms, we didn't return the list of allowed rooms
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
F-Spaces T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants