Sync can 404 with "Can't find event..." when processing some invites

[babolivier]

Until #6983 landed (shipped in 1.12.0 - March 23, 2020), we weren't upserting rows to the rooms table when receiving a new invite. We're now doing that because we need to know the version of the room the invite is for.

In some places of the code, including when handling sync, we make the assumption that if we have an event or an invite then we have the version of the room it's been sent into. When the user has an invite to a room that's not in the rooms table, this causes an error to be raised ("Room X for event Y is unknown") and syncs to 404 (with "Can't find event Y").

As of last Friday there were 1600 rooms with this issue on matrix.org (select count(*) from local_current_membership left join rooms using (room_id) where membership = 'invite' and rooms.room_id is null;).

An ideal solution would be a background update that inserts the missing rooms in the rooms table, however this isn't trivial because we don't know the version of these rooms. Inserting a room with version NULL means Synapse will assume it's v1, which can be wrong, as non-v1 room versions were introduced way earlier (v2 was introduced in #4307 and shipped in 0.34.1, released on Jan 9, 2019).

We could also do a similar update just for rooms which invite predates rooms v2, but that would probably be quite low impact (89 rooms on matrix.org).

A first step towards resolution could be to ensure we don't fail in that case unless it's necessary - e.g. we don't fail the entire sync response over one bogus invite.

[richvdh]

I'm fairly sure that this used to work correctly, so I'd be somewhat interested to know at what point it regressed. Where exactly does the /sync handler expect that there is a rooms entry?

#6902 is related in that even if your sync returns correctly, you may not be able to reject the invite.

[richvdh]

I've looked into this a little more.

First of all, it's not a recent regression, but more of an edge-case that got forgotten.

The code that relies on an entry in rooms was added in #6874 (1.12.0rc1). When I wrote that, I did consider the case of out-of-band-memberships and added a workaround (see here). However, the workaround relied on the out_of_band_membership internal metadata flag, which itself was only added in #4405 (Synapse 0.99.0).

Hence a more accurate estimate of the number of users affected is:

matrix=> select count(*) from local_current_membership lcm left join event_json ej using (event_id) left join rooms r on r.room_id = lcm.room_id where membership = 'invite' and r.room_id is null and ej.internal_metadata::json->>'out_of_band_membership' is null;
 count 
-------
    88