Skip to content

What should happen when the homeserver is unable to fetch hierarchy info about a remote room? #2237

@MadLittleMods

Description

@MadLittleMods

Link to problem area

Spaces /hierarchy endpoint (client API): https://spec.matrix.org/v1.16/client-server-api/#get_matrixclientv1roomsroomidhierarchy

Issue

Clarify the server behavior when a someone requests /hierarchy for some space but the homeserver is unable to fetch hierarchy info for some unknown remote child room over federation. This could be because the remote via servers are unreachable or because the remote homeserver returned a mangled response (doesn't pass validation).

This is a superset of #1467 which describes when the homeserver fails to fetch hierarchy information about a given m.space.child because the via servers are unreachable.

Currently, the spec doesn't say anything but I guess it's implied that the room is just omitted from the list of rooms. This is what happens in Synapse for example.


Spawning from reviewing element-hq/synapse#19021 (comment)

Potential solutions

Status quo

Perhaps the status quo is good enough. The client can find these unknown remote rooms by comparing the m.space.child in the children_state of a space compared to the other rooms they received. From a client perspective, perhaps this isn't very surprising since you would be iterating over the children_state of each space to render it out. From a server implementer perspective not familiar with this API, I had to think hard enough to realize this (spawning this issue).

When the client encounters a m.space.child that they don't have a corresponding SpaceHierarchyRoomsChunk for, they can still render the room ID from the m.space.child and the client can try to join themselves with the via servers in the m.space.child event.

In this case, we should just document expectations. After writing this issue out, I think this is the correct approach.

Include the room_id by itself

We could include a SpaceHierarchyRoomsChunk in the list of rooms that only contains the room_id by itself. This isn't that useful unless we also include the via servers otherwise clients would have to find this in the m.space.child event (not very good ergonomics).

The other problem is that currently, some fields of the SpaceHierarchyRoomsChunk are marked as Required; so a) omitting them wouldn't validate correctly and b) it would be impossible distinguish stub values from actual values if we included them.

Metadata

Metadata

Assignees

No one assigned

    Labels

    clarificationAn area where the expected behaviour is understood, but the spec could do with being more explicit

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions