Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
Speed up filtering of a single event in push #2080
Conversation
erikjohnston
assigned
richvdh
and unassigned
richvdh
Mar 29, 2017
|
(Actually, I think I will change this to work differently so we can cache things better) |
erikjohnston
assigned
NegativeMjark and
NegativeMjark
and unassigned
NegativeMjark
Apr 12, 2017
| @@ -184,11 +185,23 @@ def _bulk_get_push_rules_for_room(self, room_id, state_group, current_state_ids, | ||
| if uid in local_users_in_room: | ||
| user_ids.add(uid) | ||
| + forgotten = yield self.who_forgot_in_room( | ||
| + event.room_id, on_invalidate=cache_context.invalidate, | ||
| + ) |
NegativeMjark
Apr 20, 2017
Contributor
Why do we need to check if the user has forgotten the room? I guess it's because the user might have left the room and forgotten it but we are still getting new messages with them joined to the room over federation?
Should we be checking whether the user is currently in the room instead?
I'd really like to have some comments here to explain what we are doing and why.
erikjohnston
Apr 27, 2017
Owner
To be honest I just copied from the filtering code. I'm happy to drop it if we think we can?
NegativeMjark
Apr 27, 2017
Contributor
I think you are safe to ignore the forgotten stuff if we are only looking for rooms that the user is joined/invited to. I think you can only forget a room that you have left?
erikjohnston commentedMar 29, 2017
The filtering we do with events we're calculating the push rules for is much simpler than the general case as we know the users are currently joined in the room. This changes the
filter_events_for_clients_contextto take advantage of that fact (which was only used from push)