Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Option to suppress resource exceeded alerting #6173

Merged
merged 19 commits into from
Oct 24, 2019

Conversation

neilisfragile
Copy link
Contributor

@neilisfragile neilisfragile commented Oct 6, 2019

The expected use case is to suppress MAU limiting on small instances

@neilisfragile neilisfragile marked this pull request as ready for review October 11, 2019 13:06
@neilisfragile neilisfragile requested a review from a team October 11, 2019 13:06
@neilisfragile neilisfragile changed the title wip commit to suppress mau alerting for small instances Config option to suppress server resource limited exceeded. Oct 11, 2019
@neilisfragile neilisfragile self-assigned this Oct 11, 2019
@neilisfragile neilisfragile changed the title Config option to suppress server resource limited exceeded. Option to suppress resource exceeded alerting Oct 11, 2019
Copy link
Member

@richvdh richvdh left a 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:
Copy link
Member

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).

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Contributor Author

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.

@neilisfragile neilisfragile requested a review from richvdh October 18, 2019 12:37
@neilisfragile neilisfragile dismissed richvdh’s stale review October 22, 2019 09:14

points addressed

Copy link
Member

@richvdh richvdh left a 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}
Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

fixed

Copy link
Contributor Author

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.

synapse/server_notices/resource_limits_server_notices.py Outdated Show resolved Hide resolved
return

is_auth_blocking = False
if self._config.mau_limit_alerting:
Copy link
Member

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:
Copy link
Member

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.

@richvdh
Copy link
Member

richvdh commented Oct 22, 2019

Unrelated to the change at hand, but isn't this thing massively racy? if two calls maybe_send_server_notice_to_user happen at once, we might get several copies of the server notice?

@neilisfragile
Copy link
Contributor Author

Unrelated to the change at hand, but isn't this thing massively racy? if two calls maybe_send_server_notice_to_user happen at once, we might get several copies of the server notice?

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.

@richvdh
Copy link
Member

richvdh commented Oct 23, 2019

I can't think when multiple overlapping calls would occur

the user syncs from two devices at once?

but if they did I think it would result in a more confusing dag but continue to work as expected.

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
Copy link
Member

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

Suggested change
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 = ""
Copy link
Member

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

Suggested change
event_limit_type = ""
event_limit_type = None

Copy link
Member

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
Copy link
Member

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.

@richvdh richvdh merged commit 2794b79 into develop Oct 24, 2019
babolivier pushed a commit that referenced this pull request Sep 1, 2021
* commit '2794b7905':
  Option to suppress resource exceeded alerting (#6173)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants