-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Option to suppress resource exceeded alerting #6173
Option to suppress resource exceeded alerting #6173
Conversation
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'm struggling to follow this, I'm afraid.
@@ -91,6 +91,15 @@ def maybe_send_server_notice_to_user(self, user_id): | |||
currently_blocked, ref_events = yield self._is_room_currently_blocked(room_id) | |||
|
|||
try: | |||
if not self._config.mau_limit_alerting: |
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.
the big stack of if statements in this function is getting really hard to follow, and I'm worried that the duplicated code will get out of sync.
I think it would be clearer to make the check_auth_blocking
call (ie, everything between lines 103 and 112 as it currently stands) conditional on mau_limit_alerting
(leaving is_auth_blocking = False
if mau_limit_alerting
is false).
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.
@richvdh I've had a go a refactoring the whole area, I think it is now easier to read, albeit still inherently fiddly.
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 guess you didn't agree with my suggestion? Fair enough. It's certainly clearer now.
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.
For reference https://gist.github.com/richvdh/092934e994a2443bd184a01357c98677 Agreed that proposal is neater, but less explicit about the blocking behaviour, so will not adopt.
…sable-mau-alerting-for-small-instances
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.
couple more tweaks
ref_events ([]): The list of pinned events that are unrelated to | ||
limit blocking and need to be preserved. | ||
""" | ||
content = {"pinned": ref_events} |
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.
this seems to be an existing problem (so not necessarily for fixing as part of this PR), but why do we preserve the other events in this case and not in the _apply_limit_block_notification
case?
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.
From memory the idea was to shut everything down and so all tags should be discarded, but in retrospect this seems unhelpful.
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.
fixed
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.
unfixed, will address in a separate PR.
return | ||
|
||
is_auth_blocking = False | ||
if self._config.mau_limit_alerting: |
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.
this condition is redundant, it will always be True
@@ -91,6 +91,15 @@ def maybe_send_server_notice_to_user(self, user_id): | |||
currently_blocked, ref_events = yield self._is_room_currently_blocked(room_id) | |||
|
|||
try: | |||
if not self._config.mau_limit_alerting: |
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 guess you didn't agree with my suggestion? Fair enough. It's certainly clearer now.
Unrelated to the change at hand, but isn't this thing massively racy? if two calls |
Co-Authored-By: Richard van der Hoff <[email protected]>
…ub.com:matrix-org/synapse into neilj/disable-mau-alerting-for-small-instances
I can't think when multiple overlapping calls would occur, but if they did I think it would result in a more confusing dag but continue to work as expected. |
…sable-mau-alerting-for-small-instances
the user syncs from two devices at once?
wouldn't there be two copies of the server notice? |
|
||
if ( | ||
not self._config.mau_limit_alerting | ||
and event_limit_type is LimitBlockingTypes.MONTHLY_ACTIVE_USER |
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.
use ==
not is
except when checking for None
and event_limit_type is LimitBlockingTypes.MONTHLY_ACTIVE_USER | |
and event_limit_type == LimitBlockingTypes.MONTHLY_ACTIVE_USER |
if not self._config.mau_limit_alerting: | ||
# Alerting disabled, reset room if necessary and return | ||
is_auth_blocking = False | ||
event_limit_type = "" |
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.
None
would be a more conventional sentinel here
event_limit_type = "" | |
event_limit_type = None |
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.
shouldn't it be called limit_type
rather than event_limit_type
?
@@ -91,24 +92,28 @@ def maybe_send_server_notice_to_user(self, user_id): | |||
currently_blocked, ref_events = yield self._is_room_currently_blocked(room_id) | |||
|
|||
try: | |||
if not self._config.mau_limit_alerting: | |||
# Alerting disabled, reset room if necessary and return | |||
is_auth_blocking = False |
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.
this feels pretty redundant - indeed, you don't bother to check it at line 110. Let's just get rid of it and use event_limit_type
instead.
* commit '2794b7905': Option to suppress resource exceeded alerting (#6173)
The expected use case is to suppress MAU limiting on small instances