Skip to content
This repository was archived by the owner on Apr 26, 2024. It is now read-only.
This repository was archived by the owner on Apr 26, 2024. It is now read-only.

Faster joins: handle state which becomes invalid during de-partial-stating #13006

@richvdh

Description

@richvdh

It's entirely possible that, during the process of de-partial-stating, we discover that we accepted some piece of state which we should not have done. (Simple example: it may turn out that the sender of a piece of state was not actually in the room at the time). We may have told clients about that state, and we may even have made other event-auth or access decisions based on it.

(I think this is also possible for backfilled events even in the non-faster-joins case, though a bit less likely.)

We should figure out the ramifications of that, and do something about it.

def must_await_full_state(self, is_mine_id: Callable[[str], bool]) -> bool:
"""Check if we need to wait for full state to complete to calculate this state
If we have a state filter which is completely satisfied even with partial
state, then we don't need to await_full_state before we can return it.
Args:
is_mine_id: a callable which confirms if a given state_key matches a mxid
of a local user
"""
# TODO(faster_joins): it's not entirely clear that this is safe. In particular,
# there may be circumstances in which we return a piece of state that, once we
# resync the state, we discover is invalid. For example: if it turns out that
# the sender of a piece of state wasn't actually in the room, then clearly that
# state shouldn't have been returned.
# We should at least add some tests around this to see what happens.
# https://github.com/matrix-org/synapse/issues/13006

Metadata

Metadata

Assignees

Labels

A-Federated-Joinjoins over federation generally suckT-DefectBugs, crashes, hangs, security vulnerabilities, or other reported issues.

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions