Avoid brand new rooms in delete_old_current_state_events#7854
Avoid brand new rooms in delete_old_current_state_events#7854
delete_old_current_state_events#7854Conversation
When considering rooms to clean up in `delete_old_current_state_events`, skip rooms which we are creating, which otherwise look a bit like rooms we have left. Fixes #7834.
| # exclude rooms where we have active members | ||
| sql = """ | ||
| SELECT room_id | ||
| FROM current_state_events | ||
| FROM local_current_membership | ||
| WHERE | ||
| room_id > ? AND room_id <= ? | ||
| AND type = 'm.room.member' | ||
| AND membership = 'join' | ||
| AND state_key LIKE ? | ||
| GROUP BY room_id | ||
| """ | ||
|
|
||
| txn.execute(sql, (last_room_id, room_ids[-1], "%:" + self.server_name)) | ||
|
|
||
| txn.execute(sql, (last_room_id, room_ids[-1])) |
There was a problem hiding this comment.
these changes are unrelated, but I thought I may as well simplify it while I was here.
| creating_rooms = to_delete.difference(row[0] for row in txn) | ||
| logger.info("skipping rooms which are being deleted: %s", creating_rooms) | ||
|
|
||
| left_rooms = set(room_ids) - joined_room_ids | ||
| to_delete.difference_update(creating_rooms) | ||
|
|
||
| logger.info("Deleting current state left rooms: %r", left_rooms) | ||
| logger.info("Deleting current state left rooms: %r", to_delete) |
There was a problem hiding this comment.
Just to walk through the logic here:
- The returned rooms are ones that have forward extremities that are not the create event (i.e. they are rooms that are not being created currently).
to_deleteis modified to remove the above, meaning we're left with the rooms that are being created (saved ascreating_rooms).to_deleteis modified to removecreating_rooms, leaving only the rooms which are not being currently created. (I think this is equivalent to the intersection of the result of step 1 andto_deleteat the time of step 1, but that doesn't give you something nice to log, unfortunately.)
Not sure if it matters much, but I find the set operations easier to read using operators, e.g. to_delete -= creating_rooms (although this only works if they're both sets, I think).
There was a problem hiding this comment.
yes, your logic is correct.
I'll add some comments to clarify.
Not sure if it matters much, but I find the set operations easier to read using operators, e.g. to_delete -= creating_rooms (although this only works if they're both sets, I think).
agreed, and the fact that some of these aren't sets is the reason I had to use the wordy version.
There was a problem hiding this comment.
The added comments look great! 👍
Co-authored-by: Erik Johnston <erik@matrix.org>
* commit 'a973bcb8a': Add some tiny type annotations (#7870) Remove obsolete comment. Ensure that calls to `json.dumps` are compatible with the standard library json. (#7836) Avoid brand new rooms in `delete_old_current_state_events` (#7854) Allow accounts to be re-activated from the admin APIs. (#7847) Fix tests Fix typo Newsfile Use get_users_in_room rather than state handler in typing for speed Fix client reader sharding tests (#7853) Convert E2E key and room key handlers to async/await. (#7851) Return the proper 403 Forbidden error during errors with JWT logins. (#7844) remove `retry_on_integrity_error` wrapper for persist_events (#7848)
When considering rooms to clean up in
delete_old_current_state_events, skip rooms which we are creating, which otherwise look a bit like rooms we have left.Fixes #7834.