Rework sliding_sync backend; add SpaceService task to sync spaces#623
Merged
kevinaboos merged 3 commits intoproject-robius:mainfrom Nov 5, 2025
Merged
Conversation
Set default room list filter to something more expected: * exclude Left rooms * exclude spaces, since we sync those separately now * exclude "non-active" rooms, e.g., those that have been tombstoned and whose successor room we have already joined. Stop using the notion of `all_known_loaded_rooms`, because when filters are applied to the room list service (and even when they aren't), we will likely never actually receive the max number of rooms that the homeserver knows about our user account. Unfortunately, as far as I can tell, there is no definitive way to know if our client's RoomListService has received all of the expected rooms from the homeserver, given the currently-active filter. The existing state subscribers don't accurately represent whether we have received all *expected* rooms from the homeserver. So for now, we simply do not attempt to determine that, and allow all restored rooms to endlessly spin while waiting for that room to be received from the homeserver. Perhaps in the future we can re-create the notion of all expected rooms being fully loaded, but not for now. Maybe we can just call get_room_preview for a room if it hasn't been loaded after a certain timeout, e.g., 30-60 seconds. But that's not ideal, and it seems like the SDK definitely should have a way to determine this.
Now the "top-level" `start_matrix_client_login_and_sync()` function is responsible for monitoring its three sub-tasks: * The matrix worker task that handles incoming `MatrixRequest`s * The task that handles updates from the room list service * The task that handles updates from the space service (still in-progress)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add an initial async task that uses the
SpaceServiceto sync changes to joined spaces.Set default room list filter to something more expected:
Stop using the notion of
all_known_loaded_rooms, because when filters are applied to the room list service (and even when they aren't), we will likely never actually receive the max number of rooms that the homeserver knows about our user account.Unfortunately, as far as I can tell, there is no definitive way to know if our client's RoomListService has received all of the expected rooms from the homeserver, given the currently-active filter. The existing state subscribers don't accurately represent whether we have received all expected rooms from the homeserver.
So for now, we simply do not attempt to determine that, and allow all restored rooms to endlessly spin while waiting for that room to be received from the homeserver.
Perhaps in the future we can re-create the notion of all expected rooms being fully loaded, but not for now.
Maybe we can just call get_room_preview for a room if it hasn't been loaded after a certain timeout, e.g., 30-60 seconds. But that's not ideal, and it seems like the SDK definitely should have a way to determine this.