-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Faster joins: non-lazy_load_members
/sync
s should not block
#12989
Comments
One particular challenge here is being able to figure out which rooms have completed their state resyncs since a given |
For the record (contrary to what I may have said earlier): this is a fair way down the order of things that I agreed with dan, so maybe not the best battlefront to open right now. Having non- |
I guess the simplest thing is to add a table that stores the stream ordering of when a room completed joining? Then the sync code can check that table for new rooms. Note that we already have features for excluding rooms from |
I guess the question is more, which stream should we use? We could reuse the events stream, but that would add another complexity to an already complex stream. We could make a new one, but that would mean adding another field to the sync tokens. |
Yeah. I'm unenthusiastic about complexifying the |
Just a note of an edge case before I forget: if you see a room become un-partial-stated in a sync's window, it's important to still check that it isn't partial-stated at the end. The room could have been left and rejoined in the meantime since becoming originally un-partial-stated. |
Instead they should pretend that the room has not been joined yet.
/sync
s withlazy_load_members
turned on should continue to return the room.Blocked by:
The text was updated successfully, but these errors were encountered: