Add local_current_membership table
#6655
Conversation
Currently we rely on `current_state_events` to figure out what rooms a user was in and their last membership event in there. However, if the server leaves the room then the table may be cleaned up and that information is lost. So lets add a table that separately holds that information.
They get tracked separately from current state events if the server isn't already in the room.
erikjohnston
force-pushed
the
erikj/local_current_membership
branch
from
a421f0f to
0dba16d
Compare
There was a problem hiding this comment.
a few questions and suggestions below, but generally seems plausible.
It feels odd though. It feels like we're essentially duplicating a significant part of current_state_events mostly in order to act as a backup for when it gets cleared. Are there not easier ways to solve the problems that we are trying to solve by deleting stuff from current_state_events ?
synapse/storage/data_stores/main/schema/delta/57/local_current_membership.sql
Outdated
Show resolved
Hide resolved
synapse/storage/data_stores/main/schema/delta/57/local_current_membership.sql
Outdated
Show resolved
Hide resolved
synapse/storage/data_stores/main/schema/delta/57/local_current_membership.sql
Outdated
Show resolved
Hide resolved
We want to answer the question of I agree it feels odd, but a) I think not clearing out Given the above I'm relatively happy that we should be clearing out |
We also create the indices at startup so that we can use the table immediately.
erikjohnston
force-pushed
the
erikj/local_current_membership
branch
from
eb4513e to
74af339
Compare
synapse/storage/data_stores/main/schema/delta/57/local_current_membership.py
Show resolved
Hide resolved
synapse/storage/data_stores/main/schema/delta/57/local_current_membership.py
Outdated
Show resolved
Hide resolved
Co-Authored-By: Richard van der Hoff <[email protected]>
…cal_current_membership
Fix #6727 Related #6655 Co-authored-by: Erik Johnston <[email protected]>
The idea here is to track membership state for local users separately from
current_state_events, as currently synapse may delete the contents ofcurrent_state_eventsfor that room if its no longer joined to that room (e.g. if the server tries and rejoins and fails). This breaks things like theleavesection in/syncresponses and exporting user data.While that is a bit of an edge case, I do plan on changing synapse to delete the contents of
current_state_eventswhen the server leaves the room (to make it easy to answer the question "does the server share a room with a given remote user", and generally to remove footguns), which would then properly break those features.Two things:
The initial insertion of
local_current_membershiphappens in the delta script, which means it'll block start up. On a test on matrix.org this took ~40s, which is a while but not the end of the world. Doing it synchronously means we don't have to keep around various iterations of functions depending on the state of the various background updates, which got a bit fiddly.There is a bug where if a user gets state reset out of a room that room doesn't appear in the
leavesection of sync (due to us just deleting the row incurrent_state_events), which I haven't attempted to fix as I don't really know what we want to do there (since we don't have a leave event to pass down to clients).Note: The renaming of the functions are in a separate commit.
(This is part of the work for #6399)