-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Conversation
room_version = ret.get("room_version", RoomVersions.V1.identifier) | ||
event_format = room_version_to_event_format(room_version) | ||
room_version_id = ret.get("room_version", RoomVersions.V1.identifier) | ||
room_version = KNOWN_ROOM_VERSIONS.get(room_version_id) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this could conceivably return None
? in which case that should be documented in the docstring?
Or it should be changed to KNOWN_ROOM_VERSIONS[room_version_id]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It now raises an UnsupportedRoomVersionError
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could probably do with putting that in the docstring too.
"room_version", RoomVersions.V1.identifier | ||
) | ||
|
||
if room_version.identifier != room_version_id: | ||
raise SynapseError(400, "Room version mismatch") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure that 400 is the right response code when the remote server lies to us, but 🤷♂️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's the closest error code to "please bugger off and never sully our doors with that request again" that I know of :)
keyvalues={"room_id": room_id}, | ||
retcol="room_version", | ||
desc="get_room_version", | ||
allow_none=True, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this shouldn't be needed? the row should be there whether or not the version is updated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not 10000000% comfortable asserting that we definitely do have a row in rooms
for every single room right now
@@ -60,24 +60,31 @@ class StateGroupWorkerStore(EventsWorkerStore, SQLBaseStore): | |||
def __init__(self, database: Database, db_conn, hs): | |||
super(StateGroupWorkerStore, self).__init__(database, db_conn, hs) | |||
|
|||
@defer.inlineCallbacks | |||
def get_room_version(self, room_id): | |||
@cached(max_entries=10000) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ohhh did I miss the memo where async functions can be cached?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, yes, turns out that somewhere in the depths the cache descriptor calls run_in_background
on the cahced function
|
||
def _background_add_rooms_room_version_column_txn(txn: LoggingTransaction): | ||
sql = """ | ||
SELECT room_id, json FROM current_state_events |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this going to table-scan CSE
? shouldn't we base it on rooms
instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a unique index on (room_id, type, state_key)
so it just walks the index.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
right, but it's going to need to walk the entire index? Or am I misunderstanding how btree indexes work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, it'll iterate over each room and then look up the create event for each within that, AIUI.
The query plan for it on jki.re seems to show it doing that:
Limit (cost=1.11..12920.09 rows=1 width=1090)
-> Nested Loop (cost=1.11..12920.09 rows=1 width=1090)
-> Index Scan using current_state_events_room_id_type_state_key_key on current_state_events (cost=0.55..12846.65 rows=16 width=64)
Index Cond: ((room_id > ''::text) AND (type = 'm.room.create'::text) AND (state_key = ''::text))
-> Index Scan using event_json_event_id_key on event_json (cost=0.56..4.58 rows=1 width=1125)
Index Cond: (event_id = current_state_events.event_id)
Filter: (current_state_events.room_id = room_id)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
right, my concern is the index scan over that entire index, which is presumably huge on big servers, and it seems like a bunch of unnecessary I/O when we don't care about all the other events in that index.
this isn't a blocking comment; if you think it's going to be ok then that's fine. it was just a thought.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm reasonably sure it'll be fine. It will efficiently jump straight to the correct room ID, and jumping to the next room ID is fast (it won't have to iterate over all the state in the room, as it uses the tree structure to do it), so it should just be looking up the next room ID in the btree index, using the index to pull out the create event ID, repeating.
|
||
new_last_room_id = "" | ||
for room_id, creator, room_version_id in updates: | ||
self.db.simple_upsert_txn( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... we're expecting to find rooms which aren't currently in rooms
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nooooooooooooooooo not really. But equally I don't fancy betting on that fact, given we don't insert it in the same places we insert current_state_events
. If the rooms column doesn't exist when there is an entry in current state events then that could end up leading to badness when handling events related to it so I'm inclined to be a bit paranoid.
I could add a comment
room_version = ret.get("room_version", RoomVersions.V1.identifier) | ||
event_format = room_version_to_event_format(room_version) | ||
room_version_id = ret.get("room_version", RoomVersions.V1.identifier) | ||
room_version = KNOWN_ROOM_VERSIONS.get(room_version_id) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could probably do with putting that in the docstring too.
Synapse 1.10.0 (2020-02-12) =========================== **WARNING to client developers**: As of this release Synapse validates `client_secret` parameters in the Client-Server API as per the spec. See [\#6766](#6766) for details. Updates to the Docker image --------------------------- - Update the docker images to Alpine Linux 3.11. ([\#6897](#6897)) Synapse 1.10.0rc5 (2020-02-11) ============================== Bugfixes -------- - Fix the filtering introduced in 1.10.0rc3 to also apply to the state blocks returned by `/sync`. ([\#6884](#6884)) Synapse 1.10.0rc4 (2020-02-11) ============================== This release candidate was built incorrectly and is superceded by 1.10.0rc5. Synapse 1.10.0rc3 (2020-02-10) ============================== Features -------- - Filter out `m.room.aliases` from the CS API to mitigate abuse while a better solution is specced. ([\#6878](#6878)) Internal Changes ---------------- - Fix continuous integration failures with old versions of `pip`, which were introduced by a release of the `zipp` library. ([\#6880](#6880)) Synapse 1.10.0rc2 (2020-02-06) ============================== Bugfixes -------- - Fix an issue with cross-signing where device signatures were not sent to remote servers. ([\#6844](#6844)) - Fix to the unknown remote device detection which was introduced in 1.10.rc1. ([\#6848](#6848)) Internal Changes ---------------- - Detect unexpected sender keys on remote encrypted events and resync device lists. ([\#6850](#6850)) Synapse 1.10.0rc1 (2020-01-31) ============================== Features -------- - Add experimental support for updated authorization rules for aliases events, from [MSC2260](matrix-org/matrix-spec-proposals#2260). ([\#6787](#6787), [\#6790](#6790), [\#6794](#6794)) Bugfixes -------- - Warn if postgres database has a non-C locale, as that can cause issues when upgrading locales (e.g. due to upgrading OS). ([\#6734](#6734)) - Minor fixes to `PUT /_synapse/admin/v2/users` admin api. ([\#6761](#6761)) - Validate `client_secret` parameter using the regex provided by the Client-Server API, temporarily allowing `:` characters for older clients. The `:` character will be removed in a future release. ([\#6767](#6767)) - Fix persisting redaction events that have been redacted (or otherwise don't have a redacts key). ([\#6771](#6771)) - Fix outbound federation request metrics. ([\#6795](#6795)) - Fix bug where querying a remote user's device keys that weren't cached resulted in only returning a single device. ([\#6796](#6796)) - Fix race in federation sender worker that delayed sending of device updates. ([\#6799](#6799), [\#6800](#6800)) - Fix bug where Synapse didn't invalidate cache of remote users' devices when Synapse left a room. ([\#6801](#6801)) - Fix waking up other workers when remote server is detected to have come back online. ([\#6811](#6811)) Improved Documentation ---------------------- - Clarify documentation related to `user_dir` and `federation_reader` workers. ([\#6775](#6775)) Internal Changes ---------------- - Record room versions in the `rooms` table. ([\#6729](#6729), [\#6788](#6788), [\#6810](#6810)) - Propagate cache invalidates from workers to other workers. ([\#6748](#6748)) - Remove some unnecessary admin handler abstraction methods. ([\#6751](#6751)) - Add some debugging for media storage providers. ([\#6757](#6757)) - Detect unknown remote devices and mark cache as stale. ([\#6776](#6776), [\#6819](#6819)) - Attempt to resync remote users' devices when detected as stale. ([\#6786](#6786)) - Delete current state from the database when server leaves a room. ([\#6792](#6792)) - When a client asks for a remote user's device keys check if the local cache for that user has been marked as potentially stale. ([\#6797](#6797)) - Add background update to clean out left rooms from current state. ([\#6802](#6802), [\#6816](#6816)) - Refactoring work in preparation for changing the event redaction algorithm. ([\#6803](#6803), [\#6805](#6805), [\#6806](#6806), [\#6807](#6807), [\#6820](#6820))
This is so that we don't have to rely on pulling it out from
current_state_events
table.This includes some clean ups along the way, so reading through the commits might make sense.