2019-03-21 16:10:21 +01:00
|
|
|
# Copyright 2018, 2019 New Vector Ltd
|
|
|
|
#
|
|
|
|
# Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
# you may not use this file except in compliance with the License.
|
|
|
|
# You may obtain a copy of the License at
|
|
|
|
#
|
|
|
|
# http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
#
|
|
|
|
# Unless required by applicable law or agreed to in writing, software
|
|
|
|
# distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
# See the License for the specific language governing permissions and
|
|
|
|
# limitations under the License.
|
2022-11-16 16:25:24 +01:00
|
|
|
from typing import Tuple
|
2021-04-09 19:44:38 +02:00
|
|
|
from unittest.mock import Mock
|
2018-08-10 16:12:59 +02:00
|
|
|
|
2022-08-23 10:48:35 +02:00
|
|
|
from twisted.test.proto_helpers import MemoryReactor
|
|
|
|
|
2019-10-24 12:48:46 +02:00
|
|
|
from synapse.api.constants import EventTypes, LimitBlockingTypes, ServerNoticeMsgType
|
2018-08-17 16:21:34 +02:00
|
|
|
from synapse.api.errors import ResourceLimitError
|
Server notices: Dissociate room creation/lookup from invite (#7199)
Fixes #6815
Before figuring out whether we should alert a user on MAU, we call get_notice_room_for_user to get some info on the existing server notices room for this user. This function, if the room doesn't exist, creates it and invites the user in it. This means that, if we decide later that no server notice is needed, the user gets invited in a room with no message in it. This happens at every restart of the server, since the room ID returned by get_notice_room_for_user is cached.
This PR fixes that by moving the inviting bit to a dedicated function, that's only called when the server actually needs to send a notice to the user. A potential issue with this approach is that the room that's created by get_notice_room_for_user doesn't match how that same function looks for an existing room (i.e. it creates a room that doesn't have an invite or a join for the current user in it, so it could lead to a new room being created each time a user syncs), but I'm not sure this is a problem given it's cached until the server restarts, so that function won't run very often.
It also renames get_notice_room_for_user into get_or_create_notice_room_for_user to make what it does clearer.
2020-04-04 17:27:45 +02:00
|
|
|
from synapse.rest import admin
|
2021-08-17 13:57:58 +02:00
|
|
|
from synapse.rest.client import login, room, sync
|
2022-08-23 10:48:35 +02:00
|
|
|
from synapse.server import HomeServer
|
2018-08-10 16:12:59 +02:00
|
|
|
from synapse.server_notices.resource_limits_server_notices import (
|
|
|
|
ResourceLimitsServerNotices,
|
|
|
|
)
|
2023-02-14 20:03:35 +01:00
|
|
|
from synapse.server_notices.server_notices_sender import ServerNoticesSender
|
2023-02-08 22:29:49 +01:00
|
|
|
from synapse.types import JsonDict
|
2022-08-23 10:48:35 +02:00
|
|
|
from synapse.util import Clock
|
2018-08-10 16:12:59 +02:00
|
|
|
|
|
|
|
from tests import unittest
|
2020-08-11 23:21:20 +02:00
|
|
|
from tests.test_utils import make_awaitable
|
2020-05-22 22:47:07 +02:00
|
|
|
from tests.unittest import override_config
|
|
|
|
from tests.utils import default_config
|
2018-08-10 16:12:59 +02:00
|
|
|
|
|
|
|
|
2019-03-21 16:10:21 +01:00
|
|
|
class TestResourceLimitsServerNotices(unittest.HomeserverTestCase):
|
2023-02-08 22:29:49 +01:00
|
|
|
def default_config(self) -> JsonDict:
|
2020-05-22 22:47:07 +02:00
|
|
|
config = default_config("test")
|
|
|
|
|
|
|
|
config.update(
|
|
|
|
{
|
|
|
|
"admin_contact": "mailto:user@test.com",
|
|
|
|
"limit_usage_by_mau": True,
|
|
|
|
"server_notices": {
|
|
|
|
"system_mxid_localpart": "server",
|
|
|
|
"system_mxid_display_name": "test display name",
|
|
|
|
"system_mxid_avatar_url": None,
|
|
|
|
"room_name": "Server Notices",
|
|
|
|
},
|
|
|
|
}
|
|
|
|
)
|
|
|
|
|
|
|
|
# apply any additional config which was specified via the override_config
|
|
|
|
# decorator.
|
|
|
|
if self._extra_config is not None:
|
|
|
|
config.update(self._extra_config)
|
|
|
|
|
|
|
|
return config
|
2019-03-21 16:10:21 +01:00
|
|
|
|
2022-08-23 10:48:35 +02:00
|
|
|
def prepare(self, reactor: MemoryReactor, clock: Clock, hs: HomeServer) -> None:
|
2023-02-14 20:03:35 +01:00
|
|
|
server_notices_sender = self.hs.get_server_notices_sender()
|
|
|
|
assert isinstance(server_notices_sender, ServerNoticesSender)
|
2018-08-10 16:12:59 +02:00
|
|
|
|
|
|
|
# relying on [1] is far from ideal, but the only case where
|
|
|
|
# ResourceLimitsServerNotices class needs to be isolated is this test,
|
|
|
|
# general code should never have a reason to do so ...
|
2023-02-14 20:03:35 +01:00
|
|
|
rlsn = list(server_notices_sender._server_notices)[1]
|
|
|
|
assert isinstance(rlsn, ResourceLimitsServerNotices)
|
|
|
|
self._rlsn = rlsn
|
2018-08-10 16:12:59 +02:00
|
|
|
|
|
|
|
self._rlsn._store.user_last_seen_monthly_active = Mock(
|
2020-09-08 13:26:55 +02:00
|
|
|
return_value=make_awaitable(1000)
|
2018-08-10 16:12:59 +02:00
|
|
|
)
|
2023-01-22 10:50:14 +01:00
|
|
|
self._rlsn._server_notices_manager.send_notice = Mock( # type: ignore[assignment]
|
2022-04-27 15:58:26 +02:00
|
|
|
return_value=make_awaitable(Mock())
|
2020-05-01 16:15:36 +02:00
|
|
|
)
|
2018-08-10 16:12:59 +02:00
|
|
|
self._send_notice = self._rlsn._server_notices_manager.send_notice
|
|
|
|
|
2018-08-16 15:53:35 +02:00
|
|
|
self.user_id = "@user_id:test"
|
|
|
|
|
Server notices: Dissociate room creation/lookup from invite (#7199)
Fixes #6815
Before figuring out whether we should alert a user on MAU, we call get_notice_room_for_user to get some info on the existing server notices room for this user. This function, if the room doesn't exist, creates it and invites the user in it. This means that, if we decide later that no server notice is needed, the user gets invited in a room with no message in it. This happens at every restart of the server, since the room ID returned by get_notice_room_for_user is cached.
This PR fixes that by moving the inviting bit to a dedicated function, that's only called when the server actually needs to send a notice to the user. A potential issue with this approach is that the room that's created by get_notice_room_for_user doesn't match how that same function looks for an existing room (i.e. it creates a room that doesn't have an invite or a join for the current user in it, so it could lead to a new room being created each time a user syncs), but I'm not sure this is a problem given it's cached until the server restarts, so that function won't run very often.
It also renames get_notice_room_for_user into get_or_create_notice_room_for_user to make what it does clearer.
2020-04-04 17:27:45 +02:00
|
|
|
self._rlsn._server_notices_manager.get_or_create_notice_room_for_user = Mock(
|
2022-04-27 15:58:26 +02:00
|
|
|
return_value=make_awaitable("!something:localhost")
|
2018-08-16 15:53:35 +02:00
|
|
|
)
|
2022-05-13 15:30:15 +02:00
|
|
|
self._rlsn._server_notices_manager.maybe_get_notice_room_for_user = Mock(
|
|
|
|
return_value=make_awaitable("!something:localhost")
|
|
|
|
)
|
2023-01-22 10:50:14 +01:00
|
|
|
self._rlsn._store.add_tag_to_room = Mock(return_value=make_awaitable(None)) # type: ignore[assignment]
|
|
|
|
self._rlsn._store.get_tags_for_room = Mock(return_value=make_awaitable({})) # type: ignore[assignment]
|
2018-08-10 16:12:59 +02:00
|
|
|
|
2020-05-22 22:47:07 +02:00
|
|
|
@override_config({"hs_disabled": True})
|
2023-02-08 22:29:49 +01:00
|
|
|
def test_maybe_send_server_notice_disabled_hs(self) -> None:
|
2020-05-22 22:47:07 +02:00
|
|
|
"""If the HS is disabled, we should not send notices"""
|
2019-03-21 16:10:21 +01:00
|
|
|
self.get_success(self._rlsn.maybe_send_server_notice_to_user(self.user_id))
|
2018-08-10 16:12:59 +02:00
|
|
|
self._send_notice.assert_not_called()
|
|
|
|
|
2020-05-22 22:47:07 +02:00
|
|
|
@override_config({"limit_usage_by_mau": False})
|
2023-02-08 22:29:49 +01:00
|
|
|
def test_maybe_send_server_notice_to_user_flag_off(self) -> None:
|
2020-05-22 22:47:07 +02:00
|
|
|
"""If mau limiting is disabled, we should not send notices"""
|
|
|
|
self.get_success(self._rlsn.maybe_send_server_notice_to_user(self.user_id))
|
2018-08-10 16:12:59 +02:00
|
|
|
self._send_notice.assert_not_called()
|
|
|
|
|
2023-02-08 22:29:49 +01:00
|
|
|
def test_maybe_send_server_notice_to_user_remove_blocked_notice(self) -> None:
|
2018-08-10 16:12:59 +02:00
|
|
|
"""Test when user has blocked notice, but should have it removed"""
|
|
|
|
|
2023-02-14 20:03:35 +01:00
|
|
|
self._rlsn._auth_blocking.check_auth_blocking = Mock( # type: ignore[assignment]
|
2022-06-14 10:51:15 +02:00
|
|
|
return_value=make_awaitable(None)
|
|
|
|
)
|
2018-08-22 18:00:29 +02:00
|
|
|
mock_event = Mock(
|
2018-09-06 18:58:18 +02:00
|
|
|
type=EventTypes.Message, content={"msgtype": ServerNoticeMsgType}
|
|
|
|
)
|
2023-02-14 20:03:35 +01:00
|
|
|
self._rlsn._store.get_events = Mock( # type: ignore[assignment]
|
2020-08-18 22:20:49 +02:00
|
|
|
return_value=make_awaitable({"123": mock_event})
|
2018-08-22 18:00:29 +02:00
|
|
|
)
|
2019-03-21 16:10:21 +01:00
|
|
|
self.get_success(self._rlsn.maybe_send_server_notice_to_user(self.user_id))
|
2018-08-16 15:53:35 +02:00
|
|
|
# Would be better to check the content, but once == remove blocking event
|
2023-02-14 20:03:35 +01:00
|
|
|
maybe_get_notice_room_for_user = (
|
|
|
|
self._rlsn._server_notices_manager.maybe_get_notice_room_for_user
|
|
|
|
)
|
|
|
|
assert isinstance(maybe_get_notice_room_for_user, Mock)
|
|
|
|
maybe_get_notice_room_for_user.assert_called_once()
|
2018-08-16 15:53:35 +02:00
|
|
|
self._send_notice.assert_called_once()
|
2018-08-10 16:12:59 +02:00
|
|
|
|
2023-02-08 22:29:49 +01:00
|
|
|
def test_maybe_send_server_notice_to_user_remove_blocked_notice_noop(self) -> None:
|
2019-03-21 16:10:21 +01:00
|
|
|
"""
|
|
|
|
Test when user has blocked notice, but notice ought to be there (NOOP)
|
|
|
|
"""
|
2023-02-14 20:03:35 +01:00
|
|
|
self._rlsn._auth_blocking.check_auth_blocking = Mock( # type: ignore[assignment]
|
2022-04-27 15:58:26 +02:00
|
|
|
return_value=make_awaitable(None),
|
|
|
|
side_effect=ResourceLimitError(403, "foo"),
|
2018-08-10 16:12:59 +02:00
|
|
|
)
|
|
|
|
|
2018-08-22 18:00:29 +02:00
|
|
|
mock_event = Mock(
|
2018-09-06 18:58:18 +02:00
|
|
|
type=EventTypes.Message, content={"msgtype": ServerNoticeMsgType}
|
|
|
|
)
|
2023-02-14 20:03:35 +01:00
|
|
|
self._rlsn._store.get_events = Mock( # type: ignore[assignment]
|
2020-08-18 22:20:49 +02:00
|
|
|
return_value=make_awaitable({"123": mock_event})
|
2018-08-22 18:00:29 +02:00
|
|
|
)
|
2020-05-01 16:15:36 +02:00
|
|
|
|
2019-03-21 16:10:21 +01:00
|
|
|
self.get_success(self._rlsn.maybe_send_server_notice_to_user(self.user_id))
|
2018-08-10 16:12:59 +02:00
|
|
|
|
|
|
|
self._send_notice.assert_not_called()
|
|
|
|
|
2023-02-08 22:29:49 +01:00
|
|
|
def test_maybe_send_server_notice_to_user_add_blocked_notice(self) -> None:
|
2019-03-21 16:10:21 +01:00
|
|
|
"""
|
|
|
|
Test when user does not have blocked notice, but should have one
|
|
|
|
"""
|
2023-02-14 20:03:35 +01:00
|
|
|
self._rlsn._auth_blocking.check_auth_blocking = Mock( # type: ignore[assignment]
|
2022-04-27 15:58:26 +02:00
|
|
|
return_value=make_awaitable(None),
|
|
|
|
side_effect=ResourceLimitError(403, "foo"),
|
2018-08-17 16:21:34 +02:00
|
|
|
)
|
2019-03-21 16:10:21 +01:00
|
|
|
self.get_success(self._rlsn.maybe_send_server_notice_to_user(self.user_id))
|
2018-08-10 16:12:59 +02:00
|
|
|
|
2018-08-16 15:53:35 +02:00
|
|
|
# Would be better to check contents, but 2 calls == set blocking event
|
2019-10-24 12:48:46 +02:00
|
|
|
self.assertEqual(self._send_notice.call_count, 2)
|
2018-08-10 16:12:59 +02:00
|
|
|
|
2023-02-08 22:29:49 +01:00
|
|
|
def test_maybe_send_server_notice_to_user_add_blocked_notice_noop(self) -> None:
|
2019-03-21 16:10:21 +01:00
|
|
|
"""
|
|
|
|
Test when user does not have blocked notice, nor should they (NOOP)
|
|
|
|
"""
|
2023-02-14 20:03:35 +01:00
|
|
|
self._rlsn._auth_blocking.check_auth_blocking = Mock( # type: ignore[assignment]
|
2022-06-14 10:51:15 +02:00
|
|
|
return_value=make_awaitable(None)
|
|
|
|
)
|
2018-08-10 16:12:59 +02:00
|
|
|
|
2019-03-21 16:10:21 +01:00
|
|
|
self.get_success(self._rlsn.maybe_send_server_notice_to_user(self.user_id))
|
2018-08-10 16:12:59 +02:00
|
|
|
|
|
|
|
self._send_notice.assert_not_called()
|
|
|
|
|
2023-02-08 22:29:49 +01:00
|
|
|
def test_maybe_send_server_notice_to_user_not_in_mau_cohort(self) -> None:
|
2019-03-21 16:10:21 +01:00
|
|
|
"""
|
|
|
|
Test when user is not part of the MAU cohort - this should not ever
|
2018-08-10 16:12:59 +02:00
|
|
|
happen - but ...
|
|
|
|
"""
|
2023-02-14 20:03:35 +01:00
|
|
|
self._rlsn._auth_blocking.check_auth_blocking = Mock( # type: ignore[assignment]
|
2022-06-14 10:51:15 +02:00
|
|
|
return_value=make_awaitable(None)
|
|
|
|
)
|
2018-08-10 16:12:59 +02:00
|
|
|
self._rlsn._store.user_last_seen_monthly_active = Mock(
|
2020-09-08 13:26:55 +02:00
|
|
|
return_value=make_awaitable(None)
|
2018-08-10 16:12:59 +02:00
|
|
|
)
|
2019-03-21 16:10:21 +01:00
|
|
|
self.get_success(self._rlsn.maybe_send_server_notice_to_user(self.user_id))
|
2018-08-10 16:12:59 +02:00
|
|
|
|
|
|
|
self._send_notice.assert_not_called()
|
2018-08-23 17:20:51 +02:00
|
|
|
|
2020-05-22 22:47:07 +02:00
|
|
|
@override_config({"mau_limit_alerting": False})
|
2023-02-08 22:29:49 +01:00
|
|
|
def test_maybe_send_server_notice_when_alerting_suppressed_room_unblocked(
|
|
|
|
self,
|
|
|
|
) -> None:
|
2019-10-24 12:48:46 +02:00
|
|
|
"""
|
|
|
|
Test that when server is over MAU limit and alerting is suppressed, then
|
|
|
|
an alert message is not sent into the room
|
|
|
|
"""
|
2023-02-14 20:03:35 +01:00
|
|
|
self._rlsn._auth_blocking.check_auth_blocking = Mock( # type: ignore[assignment]
|
2022-04-27 15:58:26 +02:00
|
|
|
return_value=make_awaitable(None),
|
2019-10-24 12:48:46 +02:00
|
|
|
side_effect=ResourceLimitError(
|
|
|
|
403, "foo", limit_type=LimitBlockingTypes.MONTHLY_ACTIVE_USER
|
2020-05-01 16:15:36 +02:00
|
|
|
),
|
2019-10-24 12:48:46 +02:00
|
|
|
)
|
|
|
|
self.get_success(self._rlsn.maybe_send_server_notice_to_user(self.user_id))
|
|
|
|
|
2020-05-01 16:15:36 +02:00
|
|
|
self.assertEqual(self._send_notice.call_count, 0)
|
2019-10-24 12:48:46 +02:00
|
|
|
|
2020-05-22 22:47:07 +02:00
|
|
|
@override_config({"mau_limit_alerting": False})
|
2023-02-08 22:29:49 +01:00
|
|
|
def test_check_hs_disabled_unaffected_by_mau_alert_suppression(self) -> None:
|
2019-10-24 12:48:46 +02:00
|
|
|
"""
|
|
|
|
Test that when a server is disabled, that MAU limit alerting is ignored.
|
|
|
|
"""
|
2023-02-14 20:03:35 +01:00
|
|
|
self._rlsn._auth_blocking.check_auth_blocking = Mock( # type: ignore[assignment]
|
2022-04-27 15:58:26 +02:00
|
|
|
return_value=make_awaitable(None),
|
2019-10-24 12:48:46 +02:00
|
|
|
side_effect=ResourceLimitError(
|
|
|
|
403, "foo", limit_type=LimitBlockingTypes.HS_DISABLED
|
2020-05-01 16:15:36 +02:00
|
|
|
),
|
2019-10-24 12:48:46 +02:00
|
|
|
)
|
|
|
|
self.get_success(self._rlsn.maybe_send_server_notice_to_user(self.user_id))
|
|
|
|
|
|
|
|
# Would be better to check contents, but 2 calls == set blocking event
|
|
|
|
self.assertEqual(self._send_notice.call_count, 2)
|
|
|
|
|
2020-05-22 22:47:07 +02:00
|
|
|
@override_config({"mau_limit_alerting": False})
|
2023-02-08 22:29:49 +01:00
|
|
|
def test_maybe_send_server_notice_when_alerting_suppressed_room_blocked(
|
|
|
|
self,
|
|
|
|
) -> None:
|
2019-10-24 12:48:46 +02:00
|
|
|
"""
|
|
|
|
When the room is already in a blocked state, test that when alerting
|
|
|
|
is suppressed that the room is returned to an unblocked state.
|
|
|
|
"""
|
2023-02-14 20:03:35 +01:00
|
|
|
self._rlsn._auth_blocking.check_auth_blocking = Mock( # type: ignore[assignment]
|
2022-04-27 15:58:26 +02:00
|
|
|
return_value=make_awaitable(None),
|
2019-10-24 12:48:46 +02:00
|
|
|
side_effect=ResourceLimitError(
|
|
|
|
403, "foo", limit_type=LimitBlockingTypes.MONTHLY_ACTIVE_USER
|
2020-05-01 16:15:36 +02:00
|
|
|
),
|
2019-10-24 12:48:46 +02:00
|
|
|
)
|
2020-05-01 16:15:36 +02:00
|
|
|
|
2023-02-14 20:03:35 +01:00
|
|
|
self._rlsn._is_room_currently_blocked = Mock( # type: ignore[assignment]
|
2022-04-27 15:58:26 +02:00
|
|
|
return_value=make_awaitable((True, []))
|
2019-10-24 12:48:46 +02:00
|
|
|
)
|
|
|
|
|
|
|
|
mock_event = Mock(
|
|
|
|
type=EventTypes.Message, content={"msgtype": ServerNoticeMsgType}
|
|
|
|
)
|
2023-02-14 20:03:35 +01:00
|
|
|
self._rlsn._store.get_events = Mock( # type: ignore[assignment]
|
2020-08-18 22:20:49 +02:00
|
|
|
return_value=make_awaitable({"123": mock_event})
|
2019-10-24 12:48:46 +02:00
|
|
|
)
|
|
|
|
self.get_success(self._rlsn.maybe_send_server_notice_to_user(self.user_id))
|
|
|
|
|
|
|
|
self._send_notice.assert_called_once()
|
|
|
|
|
2018-08-23 17:20:51 +02:00
|
|
|
|
2019-03-21 16:10:21 +01:00
|
|
|
class TestResourceLimitsServerNoticesWithRealRooms(unittest.HomeserverTestCase):
|
Server notices: Dissociate room creation/lookup from invite (#7199)
Fixes #6815
Before figuring out whether we should alert a user on MAU, we call get_notice_room_for_user to get some info on the existing server notices room for this user. This function, if the room doesn't exist, creates it and invites the user in it. This means that, if we decide later that no server notice is needed, the user gets invited in a room with no message in it. This happens at every restart of the server, since the room ID returned by get_notice_room_for_user is cached.
This PR fixes that by moving the inviting bit to a dedicated function, that's only called when the server actually needs to send a notice to the user. A potential issue with this approach is that the room that's created by get_notice_room_for_user doesn't match how that same function looks for an existing room (i.e. it creates a room that doesn't have an invite or a join for the current user in it, so it could lead to a new room being created each time a user syncs), but I'm not sure this is a problem given it's cached until the server restarts, so that function won't run very often.
It also renames get_notice_room_for_user into get_or_create_notice_room_for_user to make what it does clearer.
2020-04-04 17:27:45 +02:00
|
|
|
servlets = [
|
|
|
|
admin.register_servlets,
|
|
|
|
login.register_servlets,
|
|
|
|
room.register_servlets,
|
|
|
|
sync.register_servlets,
|
|
|
|
]
|
|
|
|
|
2023-02-08 22:29:49 +01:00
|
|
|
def default_config(self) -> JsonDict:
|
Server notices: Dissociate room creation/lookup from invite (#7199)
Fixes #6815
Before figuring out whether we should alert a user on MAU, we call get_notice_room_for_user to get some info on the existing server notices room for this user. This function, if the room doesn't exist, creates it and invites the user in it. This means that, if we decide later that no server notice is needed, the user gets invited in a room with no message in it. This happens at every restart of the server, since the room ID returned by get_notice_room_for_user is cached.
This PR fixes that by moving the inviting bit to a dedicated function, that's only called when the server actually needs to send a notice to the user. A potential issue with this approach is that the room that's created by get_notice_room_for_user doesn't match how that same function looks for an existing room (i.e. it creates a room that doesn't have an invite or a join for the current user in it, so it could lead to a new room being created each time a user syncs), but I'm not sure this is a problem given it's cached until the server restarts, so that function won't run very often.
It also renames get_notice_room_for_user into get_or_create_notice_room_for_user to make what it does clearer.
2020-04-04 17:27:45 +02:00
|
|
|
c = super().default_config()
|
|
|
|
c["server_notices"] = {
|
|
|
|
"system_mxid_localpart": "server",
|
|
|
|
"system_mxid_display_name": None,
|
|
|
|
"system_mxid_avatar_url": None,
|
|
|
|
"room_name": "Test Server Notice Room",
|
|
|
|
}
|
|
|
|
c["limit_usage_by_mau"] = True
|
|
|
|
c["max_mau_value"] = 5
|
|
|
|
c["admin_contact"] = "mailto:user@test.com"
|
|
|
|
return c
|
|
|
|
|
2022-08-23 10:48:35 +02:00
|
|
|
def prepare(self, reactor: MemoryReactor, clock: Clock, hs: HomeServer) -> None:
|
2022-02-23 12:04:02 +01:00
|
|
|
self.store = self.hs.get_datastores().main
|
2018-08-23 17:20:51 +02:00
|
|
|
self.server_notices_manager = self.hs.get_server_notices_manager()
|
|
|
|
self.event_source = self.hs.get_event_sources()
|
|
|
|
|
2023-02-14 20:03:35 +01:00
|
|
|
server_notices_sender = self.hs.get_server_notices_sender()
|
|
|
|
assert isinstance(server_notices_sender, ServerNoticesSender)
|
|
|
|
|
2018-08-23 17:20:51 +02:00
|
|
|
# relying on [1] is far from ideal, but the only case where
|
|
|
|
# ResourceLimitsServerNotices class needs to be isolated is this test,
|
|
|
|
# general code should never have a reason to do so ...
|
2023-02-14 20:03:35 +01:00
|
|
|
rlsn = list(server_notices_sender._server_notices)[1]
|
|
|
|
assert isinstance(rlsn, ResourceLimitsServerNotices)
|
|
|
|
self._rlsn = rlsn
|
2018-08-23 17:20:51 +02:00
|
|
|
|
|
|
|
self.user_id = "@user_id:test"
|
|
|
|
|
2023-02-08 22:29:49 +01:00
|
|
|
def test_server_notice_only_sent_once(self) -> None:
|
2020-09-08 13:26:55 +02:00
|
|
|
self.store.get_monthly_active_count = Mock(return_value=make_awaitable(1000))
|
2018-08-23 17:20:51 +02:00
|
|
|
|
2020-05-01 16:15:36 +02:00
|
|
|
self.store.user_last_seen_monthly_active = Mock(
|
2020-09-08 13:26:55 +02:00
|
|
|
return_value=make_awaitable(1000)
|
2020-05-01 16:15:36 +02:00
|
|
|
)
|
2018-08-23 17:20:51 +02:00
|
|
|
|
|
|
|
# Call the function multiple times to ensure we only send the notice once
|
2019-03-21 16:10:21 +01:00
|
|
|
self.get_success(self._rlsn.maybe_send_server_notice_to_user(self.user_id))
|
|
|
|
self.get_success(self._rlsn.maybe_send_server_notice_to_user(self.user_id))
|
|
|
|
self.get_success(self._rlsn.maybe_send_server_notice_to_user(self.user_id))
|
2018-08-23 17:20:51 +02:00
|
|
|
|
|
|
|
# Now lets get the last load of messages in the service notice room and
|
|
|
|
# check that there is only one server notice
|
2019-03-21 16:10:21 +01:00
|
|
|
room_id = self.get_success(
|
Server notices: Dissociate room creation/lookup from invite (#7199)
Fixes #6815
Before figuring out whether we should alert a user on MAU, we call get_notice_room_for_user to get some info on the existing server notices room for this user. This function, if the room doesn't exist, creates it and invites the user in it. This means that, if we decide later that no server notice is needed, the user gets invited in a room with no message in it. This happens at every restart of the server, since the room ID returned by get_notice_room_for_user is cached.
This PR fixes that by moving the inviting bit to a dedicated function, that's only called when the server actually needs to send a notice to the user. A potential issue with this approach is that the room that's created by get_notice_room_for_user doesn't match how that same function looks for an existing room (i.e. it creates a room that doesn't have an invite or a join for the current user in it, so it could lead to a new room being created each time a user syncs), but I'm not sure this is a problem given it's cached until the server restarts, so that function won't run very often.
It also renames get_notice_room_for_user into get_or_create_notice_room_for_user to make what it does clearer.
2020-04-04 17:27:45 +02:00
|
|
|
self.server_notices_manager.get_or_create_notice_room_for_user(self.user_id)
|
2018-08-23 17:20:51 +02:00
|
|
|
)
|
|
|
|
|
2020-08-04 13:21:47 +02:00
|
|
|
token = self.event_source.get_current_token()
|
2019-03-21 16:10:21 +01:00
|
|
|
events, _ = self.get_success(
|
|
|
|
self.store.get_recent_events_for_room(
|
|
|
|
room_id, limit=100, end_token=token.room_key
|
|
|
|
)
|
2018-08-23 17:20:51 +02:00
|
|
|
)
|
|
|
|
|
|
|
|
count = 0
|
|
|
|
for event in events:
|
|
|
|
if event.type != EventTypes.Message:
|
|
|
|
continue
|
|
|
|
if event.content.get("msgtype") != ServerNoticeMsgType:
|
|
|
|
continue
|
|
|
|
|
|
|
|
count += 1
|
|
|
|
|
|
|
|
self.assertEqual(count, 1)
|
Server notices: Dissociate room creation/lookup from invite (#7199)
Fixes #6815
Before figuring out whether we should alert a user on MAU, we call get_notice_room_for_user to get some info on the existing server notices room for this user. This function, if the room doesn't exist, creates it and invites the user in it. This means that, if we decide later that no server notice is needed, the user gets invited in a room with no message in it. This happens at every restart of the server, since the room ID returned by get_notice_room_for_user is cached.
This PR fixes that by moving the inviting bit to a dedicated function, that's only called when the server actually needs to send a notice to the user. A potential issue with this approach is that the room that's created by get_notice_room_for_user doesn't match how that same function looks for an existing room (i.e. it creates a room that doesn't have an invite or a join for the current user in it, so it could lead to a new room being created each time a user syncs), but I'm not sure this is a problem given it's cached until the server restarts, so that function won't run very often.
It also renames get_notice_room_for_user into get_or_create_notice_room_for_user to make what it does clearer.
2020-04-04 17:27:45 +02:00
|
|
|
|
2023-02-08 22:29:49 +01:00
|
|
|
def test_no_invite_without_notice(self) -> None:
|
Server notices: Dissociate room creation/lookup from invite (#7199)
Fixes #6815
Before figuring out whether we should alert a user on MAU, we call get_notice_room_for_user to get some info on the existing server notices room for this user. This function, if the room doesn't exist, creates it and invites the user in it. This means that, if we decide later that no server notice is needed, the user gets invited in a room with no message in it. This happens at every restart of the server, since the room ID returned by get_notice_room_for_user is cached.
This PR fixes that by moving the inviting bit to a dedicated function, that's only called when the server actually needs to send a notice to the user. A potential issue with this approach is that the room that's created by get_notice_room_for_user doesn't match how that same function looks for an existing room (i.e. it creates a room that doesn't have an invite or a join for the current user in it, so it could lead to a new room being created each time a user syncs), but I'm not sure this is a problem given it's cached until the server restarts, so that function won't run very often.
It also renames get_notice_room_for_user into get_or_create_notice_room_for_user to make what it does clearer.
2020-04-04 17:27:45 +02:00
|
|
|
"""Tests that a user doesn't get invited to a server notices room without a
|
|
|
|
server notice being sent.
|
|
|
|
|
|
|
|
The scenario for this test is a single user on a server where the MAU limit
|
|
|
|
hasn't been reached (since it's the only user and the limit is 5), so users
|
|
|
|
shouldn't receive a server notice.
|
|
|
|
"""
|
2022-05-13 15:30:15 +02:00
|
|
|
m = Mock(return_value=make_awaitable(None))
|
|
|
|
self._rlsn._server_notices_manager.maybe_get_notice_room_for_user = m
|
|
|
|
|
|
|
|
user_id = self.register_user("user", "password")
|
Server notices: Dissociate room creation/lookup from invite (#7199)
Fixes #6815
Before figuring out whether we should alert a user on MAU, we call get_notice_room_for_user to get some info on the existing server notices room for this user. This function, if the room doesn't exist, creates it and invites the user in it. This means that, if we decide later that no server notice is needed, the user gets invited in a room with no message in it. This happens at every restart of the server, since the room ID returned by get_notice_room_for_user is cached.
This PR fixes that by moving the inviting bit to a dedicated function, that's only called when the server actually needs to send a notice to the user. A potential issue with this approach is that the room that's created by get_notice_room_for_user doesn't match how that same function looks for an existing room (i.e. it creates a room that doesn't have an invite or a join for the current user in it, so it could lead to a new room being created each time a user syncs), but I'm not sure this is a problem given it's cached until the server restarts, so that function won't run very often.
It also renames get_notice_room_for_user into get_or_create_notice_room_for_user to make what it does clearer.
2020-04-04 17:27:45 +02:00
|
|
|
tok = self.login("user", "password")
|
|
|
|
|
2020-12-15 15:44:04 +01:00
|
|
|
channel = self.make_request("GET", "/sync?timeout=0", access_token=tok)
|
Server notices: Dissociate room creation/lookup from invite (#7199)
Fixes #6815
Before figuring out whether we should alert a user on MAU, we call get_notice_room_for_user to get some info on the existing server notices room for this user. This function, if the room doesn't exist, creates it and invites the user in it. This means that, if we decide later that no server notice is needed, the user gets invited in a room with no message in it. This happens at every restart of the server, since the room ID returned by get_notice_room_for_user is cached.
This PR fixes that by moving the inviting bit to a dedicated function, that's only called when the server actually needs to send a notice to the user. A potential issue with this approach is that the room that's created by get_notice_room_for_user doesn't match how that same function looks for an existing room (i.e. it creates a room that doesn't have an invite or a join for the current user in it, so it could lead to a new room being created each time a user syncs), but I'm not sure this is a problem given it's cached until the server restarts, so that function won't run very often.
It also renames get_notice_room_for_user into get_or_create_notice_room_for_user to make what it does clearer.
2020-04-04 17:27:45 +02:00
|
|
|
|
2021-06-23 16:57:41 +02:00
|
|
|
self.assertNotIn(
|
|
|
|
"rooms", channel.json_body, "Got invites without server notice"
|
|
|
|
)
|
Server notices: Dissociate room creation/lookup from invite (#7199)
Fixes #6815
Before figuring out whether we should alert a user on MAU, we call get_notice_room_for_user to get some info on the existing server notices room for this user. This function, if the room doesn't exist, creates it and invites the user in it. This means that, if we decide later that no server notice is needed, the user gets invited in a room with no message in it. This happens at every restart of the server, since the room ID returned by get_notice_room_for_user is cached.
This PR fixes that by moving the inviting bit to a dedicated function, that's only called when the server actually needs to send a notice to the user. A potential issue with this approach is that the room that's created by get_notice_room_for_user doesn't match how that same function looks for an existing room (i.e. it creates a room that doesn't have an invite or a join for the current user in it, so it could lead to a new room being created each time a user syncs), but I'm not sure this is a problem given it's cached until the server restarts, so that function won't run very often.
It also renames get_notice_room_for_user into get_or_create_notice_room_for_user to make what it does clearer.
2020-04-04 17:27:45 +02:00
|
|
|
|
2022-05-13 15:30:15 +02:00
|
|
|
m.assert_called_once_with(user_id)
|
|
|
|
|
2023-02-08 22:29:49 +01:00
|
|
|
def test_invite_with_notice(self) -> None:
|
Server notices: Dissociate room creation/lookup from invite (#7199)
Fixes #6815
Before figuring out whether we should alert a user on MAU, we call get_notice_room_for_user to get some info on the existing server notices room for this user. This function, if the room doesn't exist, creates it and invites the user in it. This means that, if we decide later that no server notice is needed, the user gets invited in a room with no message in it. This happens at every restart of the server, since the room ID returned by get_notice_room_for_user is cached.
This PR fixes that by moving the inviting bit to a dedicated function, that's only called when the server actually needs to send a notice to the user. A potential issue with this approach is that the room that's created by get_notice_room_for_user doesn't match how that same function looks for an existing room (i.e. it creates a room that doesn't have an invite or a join for the current user in it, so it could lead to a new room being created each time a user syncs), but I'm not sure this is a problem given it's cached until the server restarts, so that function won't run very often.
It also renames get_notice_room_for_user into get_or_create_notice_room_for_user to make what it does clearer.
2020-04-04 17:27:45 +02:00
|
|
|
"""Tests that, if the MAU limit is hit, the server notices user invites each user
|
|
|
|
to a room in which it has sent a notice.
|
|
|
|
"""
|
|
|
|
user_id, tok, room_id = self._trigger_notice_and_join()
|
|
|
|
|
|
|
|
# Sync again to retrieve the events in the room, so we can check whether this
|
|
|
|
# room has a notice in it.
|
2020-12-15 15:44:04 +01:00
|
|
|
channel = self.make_request("GET", "/sync?timeout=0", access_token=tok)
|
Server notices: Dissociate room creation/lookup from invite (#7199)
Fixes #6815
Before figuring out whether we should alert a user on MAU, we call get_notice_room_for_user to get some info on the existing server notices room for this user. This function, if the room doesn't exist, creates it and invites the user in it. This means that, if we decide later that no server notice is needed, the user gets invited in a room with no message in it. This happens at every restart of the server, since the room ID returned by get_notice_room_for_user is cached.
This PR fixes that by moving the inviting bit to a dedicated function, that's only called when the server actually needs to send a notice to the user. A potential issue with this approach is that the room that's created by get_notice_room_for_user doesn't match how that same function looks for an existing room (i.e. it creates a room that doesn't have an invite or a join for the current user in it, so it could lead to a new room being created each time a user syncs), but I'm not sure this is a problem given it's cached until the server restarts, so that function won't run very often.
It also renames get_notice_room_for_user into get_or_create_notice_room_for_user to make what it does clearer.
2020-04-04 17:27:45 +02:00
|
|
|
|
|
|
|
# Scan the events in the room to search for a message from the server notices
|
|
|
|
# user.
|
|
|
|
events = channel.json_body["rooms"]["join"][room_id]["timeline"]["events"]
|
|
|
|
notice_in_room = False
|
|
|
|
for event in events:
|
|
|
|
if (
|
|
|
|
event["type"] == EventTypes.Message
|
2021-09-24 13:25:21 +02:00
|
|
|
and event["sender"] == self.hs.config.servernotices.server_notices_mxid
|
Server notices: Dissociate room creation/lookup from invite (#7199)
Fixes #6815
Before figuring out whether we should alert a user on MAU, we call get_notice_room_for_user to get some info on the existing server notices room for this user. This function, if the room doesn't exist, creates it and invites the user in it. This means that, if we decide later that no server notice is needed, the user gets invited in a room with no message in it. This happens at every restart of the server, since the room ID returned by get_notice_room_for_user is cached.
This PR fixes that by moving the inviting bit to a dedicated function, that's only called when the server actually needs to send a notice to the user. A potential issue with this approach is that the room that's created by get_notice_room_for_user doesn't match how that same function looks for an existing room (i.e. it creates a room that doesn't have an invite or a join for the current user in it, so it could lead to a new room being created each time a user syncs), but I'm not sure this is a problem given it's cached until the server restarts, so that function won't run very often.
It also renames get_notice_room_for_user into get_or_create_notice_room_for_user to make what it does clearer.
2020-04-04 17:27:45 +02:00
|
|
|
):
|
|
|
|
notice_in_room = True
|
|
|
|
|
|
|
|
self.assertTrue(notice_in_room, "No server notice in room")
|
|
|
|
|
2022-11-16 16:25:24 +01:00
|
|
|
def _trigger_notice_and_join(self) -> Tuple[str, str, str]:
|
Server notices: Dissociate room creation/lookup from invite (#7199)
Fixes #6815
Before figuring out whether we should alert a user on MAU, we call get_notice_room_for_user to get some info on the existing server notices room for this user. This function, if the room doesn't exist, creates it and invites the user in it. This means that, if we decide later that no server notice is needed, the user gets invited in a room with no message in it. This happens at every restart of the server, since the room ID returned by get_notice_room_for_user is cached.
This PR fixes that by moving the inviting bit to a dedicated function, that's only called when the server actually needs to send a notice to the user. A potential issue with this approach is that the room that's created by get_notice_room_for_user doesn't match how that same function looks for an existing room (i.e. it creates a room that doesn't have an invite or a join for the current user in it, so it could lead to a new room being created each time a user syncs), but I'm not sure this is a problem given it's cached until the server restarts, so that function won't run very often.
It also renames get_notice_room_for_user into get_or_create_notice_room_for_user to make what it does clearer.
2020-04-04 17:27:45 +02:00
|
|
|
"""Creates enough active users to hit the MAU limit and trigger a system notice
|
|
|
|
about it, then joins the system notices room with one of the users created.
|
|
|
|
|
|
|
|
Returns:
|
2022-11-16 16:25:24 +01:00
|
|
|
A tuple of:
|
|
|
|
user_id: The ID of the user that joined the room.
|
|
|
|
tok: The access token of the user that joined the room.
|
|
|
|
room_id: The ID of the room that's been joined.
|
Server notices: Dissociate room creation/lookup from invite (#7199)
Fixes #6815
Before figuring out whether we should alert a user on MAU, we call get_notice_room_for_user to get some info on the existing server notices room for this user. This function, if the room doesn't exist, creates it and invites the user in it. This means that, if we decide later that no server notice is needed, the user gets invited in a room with no message in it. This happens at every restart of the server, since the room ID returned by get_notice_room_for_user is cached.
This PR fixes that by moving the inviting bit to a dedicated function, that's only called when the server actually needs to send a notice to the user. A potential issue with this approach is that the room that's created by get_notice_room_for_user doesn't match how that same function looks for an existing room (i.e. it creates a room that doesn't have an invite or a join for the current user in it, so it could lead to a new room being created each time a user syncs), but I'm not sure this is a problem given it's cached until the server restarts, so that function won't run very often.
It also renames get_notice_room_for_user into get_or_create_notice_room_for_user to make what it does clearer.
2020-04-04 17:27:45 +02:00
|
|
|
"""
|
2023-01-22 10:50:14 +01:00
|
|
|
# We need at least one user to process
|
|
|
|
self.assertGreater(self.hs.config.server.max_mau_value, 0)
|
|
|
|
|
|
|
|
invites = {}
|
Server notices: Dissociate room creation/lookup from invite (#7199)
Fixes #6815
Before figuring out whether we should alert a user on MAU, we call get_notice_room_for_user to get some info on the existing server notices room for this user. This function, if the room doesn't exist, creates it and invites the user in it. This means that, if we decide later that no server notice is needed, the user gets invited in a room with no message in it. This happens at every restart of the server, since the room ID returned by get_notice_room_for_user is cached.
This PR fixes that by moving the inviting bit to a dedicated function, that's only called when the server actually needs to send a notice to the user. A potential issue with this approach is that the room that's created by get_notice_room_for_user doesn't match how that same function looks for an existing room (i.e. it creates a room that doesn't have an invite or a join for the current user in it, so it could lead to a new room being created each time a user syncs), but I'm not sure this is a problem given it's cached until the server restarts, so that function won't run very often.
It also renames get_notice_room_for_user into get_or_create_notice_room_for_user to make what it does clearer.
2020-04-04 17:27:45 +02:00
|
|
|
|
|
|
|
# Register as many users as the MAU limit allows.
|
2021-09-29 12:44:15 +02:00
|
|
|
for i in range(self.hs.config.server.max_mau_value):
|
Server notices: Dissociate room creation/lookup from invite (#7199)
Fixes #6815
Before figuring out whether we should alert a user on MAU, we call get_notice_room_for_user to get some info on the existing server notices room for this user. This function, if the room doesn't exist, creates it and invites the user in it. This means that, if we decide later that no server notice is needed, the user gets invited in a room with no message in it. This happens at every restart of the server, since the room ID returned by get_notice_room_for_user is cached.
This PR fixes that by moving the inviting bit to a dedicated function, that's only called when the server actually needs to send a notice to the user. A potential issue with this approach is that the room that's created by get_notice_room_for_user doesn't match how that same function looks for an existing room (i.e. it creates a room that doesn't have an invite or a join for the current user in it, so it could lead to a new room being created each time a user syncs), but I'm not sure this is a problem given it's cached until the server restarts, so that function won't run very often.
It also renames get_notice_room_for_user into get_or_create_notice_room_for_user to make what it does clearer.
2020-04-04 17:27:45 +02:00
|
|
|
localpart = "user%d" % i
|
|
|
|
user_id = self.register_user(localpart, "password")
|
|
|
|
tok = self.login(localpart, "password")
|
|
|
|
|
|
|
|
# Sync with the user's token to mark the user as active.
|
2021-02-16 23:32:34 +01:00
|
|
|
channel = self.make_request(
|
|
|
|
"GET",
|
|
|
|
"/sync?timeout=0",
|
|
|
|
access_token=tok,
|
|
|
|
)
|
Server notices: Dissociate room creation/lookup from invite (#7199)
Fixes #6815
Before figuring out whether we should alert a user on MAU, we call get_notice_room_for_user to get some info on the existing server notices room for this user. This function, if the room doesn't exist, creates it and invites the user in it. This means that, if we decide later that no server notice is needed, the user gets invited in a room with no message in it. This happens at every restart of the server, since the room ID returned by get_notice_room_for_user is cached.
This PR fixes that by moving the inviting bit to a dedicated function, that's only called when the server actually needs to send a notice to the user. A potential issue with this approach is that the room that's created by get_notice_room_for_user doesn't match how that same function looks for an existing room (i.e. it creates a room that doesn't have an invite or a join for the current user in it, so it could lead to a new room being created each time a user syncs), but I'm not sure this is a problem given it's cached until the server restarts, so that function won't run very often.
It also renames get_notice_room_for_user into get_or_create_notice_room_for_user to make what it does clearer.
2020-04-04 17:27:45 +02:00
|
|
|
|
|
|
|
# Also retrieves the list of invites for this user. We don't care about that
|
|
|
|
# one except if we're processing the last user, which should have received an
|
|
|
|
# invite to a room with a server notice about the MAU limit being reached.
|
|
|
|
# We could also pick another user and sync with it, which would return an
|
|
|
|
# invite to a system notices room, but it doesn't matter which user we're
|
|
|
|
# using so we use the last one because it saves us an extra sync.
|
2021-06-23 16:57:41 +02:00
|
|
|
if "rooms" in channel.json_body:
|
|
|
|
invites = channel.json_body["rooms"]["invite"]
|
Server notices: Dissociate room creation/lookup from invite (#7199)
Fixes #6815
Before figuring out whether we should alert a user on MAU, we call get_notice_room_for_user to get some info on the existing server notices room for this user. This function, if the room doesn't exist, creates it and invites the user in it. This means that, if we decide later that no server notice is needed, the user gets invited in a room with no message in it. This happens at every restart of the server, since the room ID returned by get_notice_room_for_user is cached.
This PR fixes that by moving the inviting bit to a dedicated function, that's only called when the server actually needs to send a notice to the user. A potential issue with this approach is that the room that's created by get_notice_room_for_user doesn't match how that same function looks for an existing room (i.e. it creates a room that doesn't have an invite or a join for the current user in it, so it could lead to a new room being created each time a user syncs), but I'm not sure this is a problem given it's cached until the server restarts, so that function won't run very often.
It also renames get_notice_room_for_user into get_or_create_notice_room_for_user to make what it does clearer.
2020-04-04 17:27:45 +02:00
|
|
|
|
|
|
|
# Make sure we have an invite to process.
|
|
|
|
self.assertEqual(len(invites), 1, invites)
|
|
|
|
|
|
|
|
# Join the room.
|
|
|
|
room_id = list(invites.keys())[0]
|
|
|
|
self.helper.join(room=room_id, user=user_id, tok=tok)
|
|
|
|
|
|
|
|
return user_id, tok, room_id
|