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

Add rooms.room_version column #6729

Merged
merged 13 commits into from
Jan 27, 2020
Merged

Add rooms.room_version column #6729

merged 13 commits into from
Jan 27, 2020

Conversation

erikjohnston
Copy link
Member

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.

@erikjohnston erikjohnston requested a review from a team January 17, 2020 16:15
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)
Copy link
Member

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]

Copy link
Member Author

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

Copy link
Member

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/handlers/federation.py Show resolved Hide resolved
"room_version", RoomVersions.V1.identifier
)

if room_version.identifier != room_version_id:
raise SynapseError(400, "Room version mismatch")
Copy link
Member

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 🤷‍♂️

Copy link
Member Author

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 :)

synapse/storage/data_stores/main/state.py Outdated Show resolved Hide resolved
keyvalues={"room_id": room_id},
retcol="room_version",
desc="get_room_version",
allow_none=True,
Copy link
Member

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?

Copy link
Member Author

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

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?

Copy link
Member Author

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

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?

Copy link
Member Author

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.

Copy link
Member

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?

Copy link
Member Author

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)

Copy link
Member

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.

Copy link
Member Author

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

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?

Copy link
Member Author

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

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.

@erikjohnston erikjohnston merged commit 8df862e into develop Jan 27, 2020
richvdh added a commit that referenced this pull request Jan 31, 2020
Fixes a confusion about whether room_version is a string or an object.

This was introduced in #6729 and half-fixed in #6788.
@erikjohnston erikjohnston deleted the erikj/room_version_column branch February 5, 2020 17:35
babolivier added a commit that referenced this pull request Feb 12, 2020
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))
babolivier pushed a commit that referenced this pull request Sep 1, 2021
* commit '8df862e45':
  Add `rooms.room_version` column (#6729)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants