Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sliding sync: Add connection tracking to the account_data extension #17695

Merged
merged 13 commits into from
Sep 19, 2024

Conversation

erikjohnston
Copy link
Member

@erikjohnston erikjohnston commented Sep 11, 2024

This is basically exactly the same logic as for receipts. Essentially we just need to track which room account data we have and haven't sent down to clients, and use that when we pull stuff out.

I think this just needs a couple of extra tests written

@MadLittleMods MadLittleMods changed the title Sliding sync: fix up room account data to properly handle lists Sliding sync: Add connection tracking to the account_data extension Sep 17, 2024
@MadLittleMods MadLittleMods marked this pull request as ready for review September 17, 2024 21:32
@MadLittleMods MadLittleMods requested a review from a team as a code owner September 17, 2024 21:32
# and return the set of tags at that time but we don't track
# changes to tags so we just have to return all tags for the
# room.
immutable_tag_map = await self.store.get_tags_for_room(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cache for get_tags_for_room(...) is being added in #17730

erikjohnston pushed a commit that referenced this pull request Sep 19, 2024
Add cache to `get_tags_for_room(...)`

This helps Sliding Sync because `get_tags_for_room(...)` is going to be
used in #17695

Essentially, we're just trying to match `get_account_data_for_room(...)`
which already has a tree cache.
immutable_tag_map = await self.store.get_tags_for_room(
user_id, room_id
)
if immutable_tag_map:
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't it valid if we remove all tags from the room?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, I think you're right. It does make sense to show an empty set of tags in an incremental sync if they changed

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated, check if the tests match your expectations

@@ -480,6 +482,337 @@ def test_room_account_data_incremental_sync(self) -> None:
{"tags": {"m.favourite": {}, "m.server_notice": {}}},
)

def test_room_account_data_incremental_sync_out_of_range_never(self) -> None:
"""Tests that we don't return account data for rooms that fall out of
range, but then do send all account data once they're back in range.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like the doc for PREVIOUSLY rather than NEVER

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated

Tests that we don't return account data for rooms that are out of
range, but then do send all account data once they're in range.

Comment on lines +556 to +558
{AccountDataTypes.TAG: {"tags": immutable_tag_map}}
if immutable_tag_map
else {},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to always return tags in an intial sync?

The problem is we can't tell no tag account data from empty set of tags.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably don't? Though I don't think it really matters

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I got it right. Only show the empty tag set if we previously told the client about tags. Check if the tests match your expectations

Copy link
Member Author

@erikjohnston erikjohnston left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, but I can't approve as i opened the PR...

@MadLittleMods
Copy link
Contributor

MadLittleMods commented Sep 19, 2024

Feels like I shouldn't self-approve my own work 🤔

Update: Actually, I can just approve for you since it's just a technicality for you and the PR also looks good to me.

Copy link
Contributor

@MadLittleMods MadLittleMods left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving on behalf of @erikjohnston

@erikjohnston erikjohnston merged commit a851f6b into develop Sep 19, 2024
39 checks passed
@erikjohnston erikjohnston deleted the erikj/account_data branch September 19, 2024 18:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants