| Commit message (Collapse) | Author | Files | Lines |
|
Only run prepare_database on connection for in-memory databases.
Fixes #6569.
|
|
Fixes #6575
|
|
|
|
|
|
|
|
Previously we tried to be clever and filter out some unnecessary event
IDs to keep the auth chain small, but that had some annoying
interactions with state res v2 so we stop doing that for now.
|
|
|
|
Co-Authored-By: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
|
|
|
|
|
|
(#6527)
This fixes a weird bug where, if you were determined enough, you could end up with a rejected event forming part of the state at a backwards-extremity. Authing that backwards extrem would then lead to us trying to pull the rejected event from the db (with allow_rejected=False), which would fail with a 404.
|
|
The main point here is to make sure that the state returned by _get_state_in_room has been authed before we try to use it as state in the room.
|
|
When we perform state resolution, check that all of the events involved are in
the right room.
|
|
When we do an event auth operation, check that all of the events involved are
in the right room.
|
|
When we request the state/auth_events to populate a backwards extremity (on
backfill or in the case of missing events in a transaction push), we should
check that the returned events are in the right room rather than blindly using
them in the room state or auth chain.
Given that _get_events_from_store_or_dest takes a room_id, it seems clear that
it should be sanity-checking the room_id of the requested |