This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
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.
Allow admins to proactively block rooms #11228
Allow admins to proactively block rooms #11228
Changes from 13 commits
7e6e9da
33afbeb
47fd059
033adb7
0ed7a31
933197b
3bd4984
92efc62
b820b60
8f9bf40
a2da438
de6aa37
c5fccfa
e397068
5402a69
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I almost feel as though we want to pull the room blocking bit out of this function and put the logic into
_delete_room
. Then only callshutdown_room
andpurge_room
if the room is known. That may make the control flow slightly simpler?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was a little reluctant here.
I didn't like the idea that the block could succeed only for the shutdown/purge to fail; I'd rather the whole thing succeed or fail atomically. But that's the situation today and wouldn't be introduced by your change. It would maybe mean checking twice that a room exists, which is a bit sad.
I'm kinda of the view that this is best left alone for now---I feel like blocking might merit being its own separate API call. How does that sit with you?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure if a simple block needs a new API. But I suspect it.
I am try to bring the delete API to a background task. #11223
I do not know how to handle a simple block in V2 API. A block request bring to background is not a good solution. If I am a user, I would except to get a response immediately.
An alternative for V2 API is to response for a simple block other than a shutdown or purge. But I do not like an API with two different return types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is related to #5575.
Maybe should the API return if the blocked room is known or unknown for the Homeserver.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think shutting down a room should still block it, but separating a single block out into its own API call does sound like it'd be cleaner and better long-term. Leaving this alone for now with the hope of refactoring it all later sounds fine. Can you write up a ticket for the idea?
@dklimpel placing the shutdown room handling into a background process does sound like something that should happen regardless. I'm not sure how it relates to moving blocking of a room into a separate API however. Room blocking should be a relatively quick process.