2017-11-16 19:51:44 +01:00
|
|
|
# See https://zulip.readthedocs.io/en/latest/subsystems/events-system.html for
|
2017-02-12 01:59:28 +01:00
|
|
|
# high-level documentation on how this system works.
|
2020-06-11 00:54:34 +02:00
|
|
|
import copy
|
|
|
|
import logging
|
|
|
|
import os
|
|
|
|
import random
|
|
|
|
import time
|
2020-04-09 18:31:04 +02:00
|
|
|
import traceback
|
2022-09-16 03:48:59 +02:00
|
|
|
import uuid
|
2020-06-11 00:54:34 +02:00
|
|
|
from collections import deque
|
2024-07-12 02:30:25 +02:00
|
|
|
from collections.abc import Callable, Collection, Iterable, Mapping, MutableMapping, Sequence
|
|
|
|
from collections.abc import Set as AbstractSet
|
2023-01-18 05:25:49 +01:00
|
|
|
from contextlib import suppress
|
2024-04-02 00:19:08 +02:00
|
|
|
from functools import cache
|
2024-07-12 02:30:25 +02:00
|
|
|
from typing import Any, Literal, TypedDict, cast
|
2020-06-11 00:54:34 +02:00
|
|
|
|
2020-08-07 01:09:47 +02:00
|
|
|
import orjson
|
2016-10-18 02:57:41 +02:00
|
|
|
import tornado.ioloop
|
2020-06-11 00:54:34 +02:00
|
|
|
from django.conf import settings
|
2021-04-16 00:57:30 +02:00
|
|
|
from django.utils.translation import gettext as _
|
2022-03-17 22:09:11 +01:00
|
|
|
from tornado import autoreload
|
2023-10-12 19:43:45 +02:00
|
|
|
from typing_extensions import override
|
2020-06-11 00:54:34 +02:00
|
|
|
|
2021-07-30 12:25:53 +02:00
|
|
|
from version import API_FEATURE_LEVEL, ZULIP_MERGE_BASE, ZULIP_VERSION
|
2021-07-16 22:11:10 +02:00
|
|
|
from zerver.lib.exceptions import JsonableError
|
2023-10-03 03:25:57 +02:00
|
|
|
from zerver.lib.message_cache import MessageDict
|
2023-06-30 02:48:22 +02:00
|
|
|
from zerver.lib.narrow_helpers import narrow_dataclasses_from_tuples
|
2024-04-15 23:10:59 +02:00
|
|
|
from zerver.lib.narrow_predicate import build_narrow_predicate
|
2021-06-21 16:48:13 +02:00
|
|
|
from zerver.lib.notification_data import UserMessageNotificationsData
|
2020-04-09 18:31:04 +02:00
|
|
|
from zerver.lib.queue import queue_json_publish, retry_event
|
2020-06-11 00:54:34 +02:00
|
|
|
from zerver.middleware import async_request_timer_restart
|
2022-10-27 19:05:10 +02:00
|
|
|
from zerver.models import CustomProfileField
|
2016-11-27 06:14:48 +01:00
|
|
|
from zerver.tornado.descriptors import clear_descriptor_by_handler_id, set_descriptor_by_handler_id
|
2017-07-21 02:20:31 +02:00
|
|
|
from zerver.tornado.exceptions import BadEventQueueIdError
|
2023-12-07 20:20:54 +01:00
|
|
|
from zerver.tornado.handlers import finish_handler, get_handler_by_id, handler_stats_string
|
2016-08-30 12:03:01 +02:00
|
|
|
|
2013-04-18 22:17:48 +02:00
|
|
|
# The idle timeout used to be a week, but we found that in that
|
|
|
|
# situation, queues from dead browser sessions would grow quite large
|
|
|
|
# due to the accumulation of message data in those queues.
|
2018-12-05 23:48:40 +01:00
|
|
|
DEFAULT_EVENT_QUEUE_TIMEOUT_SECS = 60 * 10
|
2018-12-05 23:30:17 +01:00
|
|
|
# We garbage-collect every minute; this is totally fine given that the
|
|
|
|
# GC scan takes ~2ms with 1000 event queues.
|
|
|
|
EVENT_QUEUE_GC_FREQ_MSECS = 1000 * 60 * 1
|
2013-08-05 22:09:12 +02:00
|
|
|
|
|
|
|
# Capped limit for how long a client can request an event queue
|
|
|
|
# to live
|
|
|
|
MAX_QUEUE_TIMEOUT_SECS = 7 * 24 * 60 * 60
|
|
|
|
|
2013-03-28 22:39:43 +01:00
|
|
|
# The heartbeats effectively act as a server-side timeout for
|
|
|
|
# get_events(). The actual timeout value is randomized for each
|
|
|
|
# client connection based on the below value. We ensure that the
|
|
|
|
# maximum timeout value is 55 seconds, to deal with crappy home
|
|
|
|
# wireless routers that kill "inactive" http connections.
|
|
|
|
HEARTBEAT_MIN_FREQ_SECS = 45
|
2013-03-26 18:06:00 +01:00
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
2024-07-12 02:30:17 +02:00
|
|
|
def create_heartbeat_event() -> dict[str, str]:
|
2021-07-02 02:13:55 +02:00
|
|
|
return dict(type="heartbeat")
|
|
|
|
|
|
|
|
|
2017-11-05 11:52:10 +01:00
|
|
|
class ClientDescriptor:
|
2021-02-12 08:19:30 +01:00
|
|
|
def __init__(
|
|
|
|
self,
|
|
|
|
user_profile_id: int,
|
|
|
|
realm_id: int,
|
2021-02-12 08:20:45 +01:00
|
|
|
event_queue: "EventQueue",
|
2024-07-12 02:30:23 +02:00
|
|
|
event_types: Sequence[str] | None,
|
2021-02-12 08:19:30 +01:00
|
|
|
client_type_name: str,
|
|
|
|
apply_markdown: bool = True,
|
|
|
|
client_gravatar: bool = True,
|
|
|
|
slim_presence: bool = False,
|
|
|
|
all_public_streams: bool = False,
|
|
|
|
lifespan_secs: int = 0,
|
2021-04-30 00:15:33 +02:00
|
|
|
narrow: Collection[Sequence[str]] = [],
|
2021-02-12 08:19:30 +01:00
|
|
|
bulk_message_deletion: bool = False,
|
2021-04-18 18:12:35 +02:00
|
|
|
stream_typing_notifications: bool = False,
|
2021-07-24 19:51:25 +02:00
|
|
|
user_settings_object: bool = False,
|
2022-10-27 19:05:10 +02:00
|
|
|
pronouns_field_type_supported: bool = True,
|
linkifier: Support URL templates for linkifiers.
This swaps out url_format_string from all of our APIs and replaces it
with url_template. Note that the documentation changes in the following
commits will be squashed with this commit.
We change the "url_format" key to "url_template" for the
realm_linkifiers events in event_schema, along with updating
LinkifierDict. "url_template" is the name chosen to normalize
mixed usages of "url_format_string" and "url_format" throughout
the backend.
The markdown processor is updated to stop handling the format string
interpolation and delegate the task template expansion to the uri_template
library instead.
This change affects many test cases. We mostly just replace "%(name)s"
with "{name}", "url_format_string" with "url_template" to make sure that
they still pass. There are some test cases dedicated for testing "%"
escaping, which aren't relevant anymore and are subject to removal.
But for now we keep most of them as-is, and make sure that "%" is always
escaped since we do not use it for variable substitution any more.
Since url_format_string is not populated anymore, a migration is created
to remove this field entirely, and make url_template non-nullable since
we will always populate it. Note that it is possible to have
url_template being null after migration 0422 and before 0424, but
in practice, url_template will not be None after backfilling and the
backend now is always setting url_template.
With the removal of url_format_string, RealmFilter model will now be cleaned
with URL template checks, and the old checks for escapes are removed.
We also modified RealmFilter.clean to skip the validation when the
url_template is invalid. This avoids raising mulitple ValidationError's
when calling full_clean on a linkifier. But we might eventually want to
have a more centric approach to data validation instead of having
the same validation in both the clean method and the validator.
Fixes #23124.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
2022-10-05 20:55:31 +02:00
|
|
|
linkifier_url_template: bool = False,
|
2023-10-24 19:47:39 +02:00
|
|
|
user_list_incomplete: bool = False,
|
2024-09-12 11:46:48 +02:00
|
|
|
include_deactivated_groups: bool = False,
|
2024-01-18 16:38:48 +01:00
|
|
|
archived_channels: bool = False,
|
2021-02-12 08:19:30 +01:00
|
|
|
) -> None:
|
2023-06-28 20:50:39 +02:00
|
|
|
# TODO: We eventually want to upstream this code to the caller, but
|
|
|
|
# serialization concerns make it a bit difficult.
|
|
|
|
modern_narrow = narrow_dataclasses_from_tuples(narrow)
|
|
|
|
|
2013-11-19 23:51:32 +01:00
|
|
|
# These objects are serialized on shutdown and restored on restart.
|
2013-10-17 23:51:25 +02:00
|
|
|
# If fields are added or semantics are changed, temporary code must be
|
2013-11-19 23:51:32 +01:00
|
|
|
# added to load_event_queues() to update the restored objects.
|
|
|
|
# Additionally, the to_dict and from_dict methods must be updated
|
2013-03-26 18:06:00 +01:00
|
|
|
self.user_profile_id = user_profile_id
|
2013-10-17 23:51:25 +02:00
|
|
|
self.realm_id = realm_id
|
2024-07-12 02:30:23 +02:00
|
|
|
self.current_handler_id: int | None = None
|
|
|
|
self.current_client_name: str | None = None
|
2013-11-19 23:11:53 +01:00
|
|
|
self.event_queue = event_queue
|
2013-03-22 22:43:49 +01:00
|
|
|
self.event_types = event_types
|
2013-03-26 18:06:00 +01:00
|
|
|
self.last_connection_time = time.time()
|
|
|
|
self.apply_markdown = apply_markdown
|
2017-10-31 18:36:18 +01:00
|
|
|
self.client_gravatar = client_gravatar
|
2020-02-02 17:29:05 +01:00
|
|
|
self.slim_presence = slim_presence
|
2013-10-17 23:51:25 +02:00
|
|
|
self.all_public_streams = all_public_streams
|
2014-01-28 18:13:41 +01:00
|
|
|
self.client_type_name = client_type_name
|
python: Convert assignment type annotations to Python 3.6 style.
This commit was split by tabbott; this piece covers the vast majority
of files in Zulip, but excludes scripts/, tools/, and puppet/ to help
ensure we at least show the right error messages for Xenial systems.
We can likely further refine the remaining pieces with some testing.
Generated by com2ann, with whitespace fixes and various manual fixes
for runtime issues:
- invoiced_through: Optional[LicenseLedger] = models.ForeignKey(
+ invoiced_through: Optional["LicenseLedger"] = models.ForeignKey(
-_apns_client: Optional[APNsClient] = None
+_apns_client: Optional["APNsClient"] = None
- notifications_stream: Optional[Stream] = models.ForeignKey('Stream', related_name='+', null=True, blank=True, on_delete=CASCADE)
- signup_notifications_stream: Optional[Stream] = models.ForeignKey('Stream', related_name='+', null=True, blank=True, on_delete=CASCADE)
+ notifications_stream: Optional["Stream"] = models.ForeignKey('Stream', related_name='+', null=True, blank=True, on_delete=CASCADE)
+ signup_notifications_stream: Optional["Stream"] = models.ForeignKey('Stream', related_name='+', null=True, blank=True, on_delete=CASCADE)
- author: Optional[UserProfile] = models.ForeignKey('UserProfile', blank=True, null=True, on_delete=CASCADE)
+ author: Optional["UserProfile"] = models.ForeignKey('UserProfile', blank=True, null=True, on_delete=CASCADE)
- bot_owner: Optional[UserProfile] = models.ForeignKey('self', null=True, on_delete=models.SET_NULL)
+ bot_owner: Optional["UserProfile"] = models.ForeignKey('self', null=True, on_delete=models.SET_NULL)
- default_sending_stream: Optional[Stream] = models.ForeignKey('zerver.Stream', null=True, related_name='+', on_delete=CASCADE)
- default_events_register_stream: Optional[Stream] = models.ForeignKey('zerver.Stream', null=True, related_name='+', on_delete=CASCADE)
+ default_sending_stream: Optional["Stream"] = models.ForeignKey('zerver.Stream', null=True, related_name='+', on_delete=CASCADE)
+ default_events_register_stream: Optional["Stream"] = models.ForeignKey('zerver.Stream', null=True, related_name='+', on_delete=CASCADE)
-descriptors_by_handler_id: Dict[int, ClientDescriptor] = {}
+descriptors_by_handler_id: Dict[int, "ClientDescriptor"] = {}
-worker_classes: Dict[str, Type[QueueProcessingWorker]] = {}
-queues: Dict[str, Dict[str, Type[QueueProcessingWorker]]] = {}
+worker_classes: Dict[str, Type["QueueProcessingWorker"]] = {}
+queues: Dict[str, Dict[str, Type["QueueProcessingWorker"]]] = {}
-AUTH_LDAP_REVERSE_EMAIL_SEARCH: Optional[LDAPSearch] = None
+AUTH_LDAP_REVERSE_EMAIL_SEARCH: Optional["LDAPSearch"] = None
Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
2020-04-22 01:09:50 +02:00
|
|
|
self._timeout_handle: Any = None # TODO: should be return type of ioloop.call_later
|
2013-12-11 23:27:36 +01:00
|
|
|
self.narrow = narrow
|
2023-06-29 22:41:44 +02:00
|
|
|
self.narrow_predicate = build_narrow_predicate(modern_narrow)
|
2020-06-10 13:47:08 +02:00
|
|
|
self.bulk_message_deletion = bulk_message_deletion
|
2021-04-18 18:12:35 +02:00
|
|
|
self.stream_typing_notifications = stream_typing_notifications
|
2021-07-24 19:51:25 +02:00
|
|
|
self.user_settings_object = user_settings_object
|
2022-10-27 19:05:10 +02:00
|
|
|
self.pronouns_field_type_supported = pronouns_field_type_supported
|
linkifier: Support URL templates for linkifiers.
This swaps out url_format_string from all of our APIs and replaces it
with url_template. Note that the documentation changes in the following
commits will be squashed with this commit.
We change the "url_format" key to "url_template" for the
realm_linkifiers events in event_schema, along with updating
LinkifierDict. "url_template" is the name chosen to normalize
mixed usages of "url_format_string" and "url_format" throughout
the backend.
The markdown processor is updated to stop handling the format string
interpolation and delegate the task template expansion to the uri_template
library instead.
This change affects many test cases. We mostly just replace "%(name)s"
with "{name}", "url_format_string" with "url_template" to make sure that
they still pass. There are some test cases dedicated for testing "%"
escaping, which aren't relevant anymore and are subject to removal.
But for now we keep most of them as-is, and make sure that "%" is always
escaped since we do not use it for variable substitution any more.
Since url_format_string is not populated anymore, a migration is created
to remove this field entirely, and make url_template non-nullable since
we will always populate it. Note that it is possible to have
url_template being null after migration 0422 and before 0424, but
in practice, url_template will not be None after backfilling and the
backend now is always setting url_template.
With the removal of url_format_string, RealmFilter model will now be cleaned
with URL template checks, and the old checks for escapes are removed.
We also modified RealmFilter.clean to skip the validation when the
url_template is invalid. This avoids raising mulitple ValidationError's
when calling full_clean on a linkifier. But we might eventually want to
have a more centric approach to data validation instead of having
the same validation in both the clean method and the validator.
Fixes #23124.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
2022-10-05 20:55:31 +02:00
|
|
|
self.linkifier_url_template = linkifier_url_template
|
2023-10-24 19:47:39 +02:00
|
|
|
self.user_list_incomplete = user_list_incomplete
|
2024-09-12 11:46:48 +02:00
|
|
|
self.include_deactivated_groups = include_deactivated_groups
|
2024-01-18 16:38:48 +01:00
|
|
|
self.archived_channels = archived_channels
|
2013-03-22 23:25:37 +01:00
|
|
|
|
2018-12-05 23:48:40 +01:00
|
|
|
# Default for lifespan_secs is DEFAULT_EVENT_QUEUE_TIMEOUT_SECS;
|
2018-12-05 23:45:24 +01:00
|
|
|
# but users can set it as high as MAX_QUEUE_TIMEOUT_SECS.
|
2018-12-05 23:49:54 +01:00
|
|
|
if lifespan_secs == 0:
|
2018-12-05 23:48:40 +01:00
|
|
|
lifespan_secs = DEFAULT_EVENT_QUEUE_TIMEOUT_SECS
|
2018-12-05 23:45:24 +01:00
|
|
|
self.queue_timeout = min(lifespan_secs, MAX_QUEUE_TIMEOUT_SECS)
|
2013-08-05 22:09:12 +02:00
|
|
|
|
2024-07-12 02:30:17 +02:00
|
|
|
def to_dict(self) -> dict[str, Any]:
|
2013-11-22 20:30:32 +01:00
|
|
|
# If you add a new key to this dict, make sure you add appropriate
|
|
|
|
# migration code in from_dict or load_event_queues to account for
|
|
|
|
# loading event queues that lack that key.
|
2021-02-12 08:19:30 +01:00
|
|
|
return dict(
|
|
|
|
user_profile_id=self.user_profile_id,
|
|
|
|
realm_id=self.realm_id,
|
|
|
|
event_queue=self.event_queue.to_dict(),
|
|
|
|
queue_timeout=self.queue_timeout,
|
|
|
|
event_types=self.event_types,
|
|
|
|
last_connection_time=self.last_connection_time,
|
|
|
|
apply_markdown=self.apply_markdown,
|
|
|
|
client_gravatar=self.client_gravatar,
|
|
|
|
slim_presence=self.slim_presence,
|
|
|
|
all_public_streams=self.all_public_streams,
|
|
|
|
narrow=self.narrow,
|
|
|
|
client_type_name=self.client_type_name,
|
|
|
|
bulk_message_deletion=self.bulk_message_deletion,
|
2021-04-18 18:12:35 +02:00
|
|
|
stream_typing_notifications=self.stream_typing_notifications,
|
2021-07-24 19:51:25 +02:00
|
|
|
user_settings_object=self.user_settings_object,
|
2022-10-27 19:05:10 +02:00
|
|
|
pronouns_field_type_supported=self.pronouns_field_type_supported,
|
linkifier: Support URL templates for linkifiers.
This swaps out url_format_string from all of our APIs and replaces it
with url_template. Note that the documentation changes in the following
commits will be squashed with this commit.
We change the "url_format" key to "url_template" for the
realm_linkifiers events in event_schema, along with updating
LinkifierDict. "url_template" is the name chosen to normalize
mixed usages of "url_format_string" and "url_format" throughout
the backend.
The markdown processor is updated to stop handling the format string
interpolation and delegate the task template expansion to the uri_template
library instead.
This change affects many test cases. We mostly just replace "%(name)s"
with "{name}", "url_format_string" with "url_template" to make sure that
they still pass. There are some test cases dedicated for testing "%"
escaping, which aren't relevant anymore and are subject to removal.
But for now we keep most of them as-is, and make sure that "%" is always
escaped since we do not use it for variable substitution any more.
Since url_format_string is not populated anymore, a migration is created
to remove this field entirely, and make url_template non-nullable since
we will always populate it. Note that it is possible to have
url_template being null after migration 0422 and before 0424, but
in practice, url_template will not be None after backfilling and the
backend now is always setting url_template.
With the removal of url_format_string, RealmFilter model will now be cleaned
with URL template checks, and the old checks for escapes are removed.
We also modified RealmFilter.clean to skip the validation when the
url_template is invalid. This avoids raising mulitple ValidationError's
when calling full_clean on a linkifier. But we might eventually want to
have a more centric approach to data validation instead of having
the same validation in both the clean method and the validator.
Fixes #23124.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
2022-10-05 20:55:31 +02:00
|
|
|
linkifier_url_template=self.linkifier_url_template,
|
2023-10-24 19:47:39 +02:00
|
|
|
user_list_incomplete=self.user_list_incomplete,
|
2024-09-12 11:46:48 +02:00
|
|
|
include_deactivated_groups=self.include_deactivated_groups,
|
2024-01-18 16:38:48 +01:00
|
|
|
archived_channels=self.archived_channels,
|
2021-02-12 08:19:30 +01:00
|
|
|
)
|
2013-11-19 23:51:32 +01:00
|
|
|
|
2023-10-12 19:43:45 +02:00
|
|
|
@override
|
2017-11-27 11:09:23 +01:00
|
|
|
def __repr__(self) -> str:
|
2020-06-10 06:41:04 +02:00
|
|
|
return f"ClientDescriptor<{self.event_queue.id}>"
|
2016-03-20 23:59:29 +01:00
|
|
|
|
2013-11-19 23:51:32 +01:00
|
|
|
@classmethod
|
2021-02-12 08:20:45 +01:00
|
|
|
def from_dict(cls, d: MutableMapping[str, Any]) -> "ClientDescriptor":
|
|
|
|
if "client_type" in d:
|
2016-01-27 17:04:38 +01:00
|
|
|
# Temporary migration for the rename of client_type to client_type_name
|
2021-02-12 08:20:45 +01:00
|
|
|
d["client_type_name"] = d["client_type"]
|
|
|
|
if "client_gravatar" not in d:
|
2017-10-31 18:36:18 +01:00
|
|
|
# Temporary migration for the addition of the client_gravatar field
|
2021-02-12 08:20:45 +01:00
|
|
|
d["client_gravatar"] = False
|
2017-10-31 18:36:18 +01:00
|
|
|
|
2021-02-12 08:20:45 +01:00
|
|
|
if "slim_presence" not in d:
|
|
|
|
d["slim_presence"] = False
|
2020-02-02 17:29:05 +01:00
|
|
|
|
2017-10-31 18:36:18 +01:00
|
|
|
ret = cls(
|
2021-02-12 08:20:45 +01:00
|
|
|
d["user_profile_id"],
|
|
|
|
d["realm_id"],
|
|
|
|
EventQueue.from_dict(d["event_queue"]),
|
|
|
|
d["event_types"],
|
|
|
|
d["client_type_name"],
|
|
|
|
d["apply_markdown"],
|
|
|
|
d["client_gravatar"],
|
|
|
|
d["slim_presence"],
|
|
|
|
d["all_public_streams"],
|
|
|
|
d["queue_timeout"],
|
|
|
|
d.get("narrow", []),
|
|
|
|
d.get("bulk_message_deletion", False),
|
2021-04-18 18:12:35 +02:00
|
|
|
d.get("stream_typing_notifications", False),
|
2021-07-24 19:51:25 +02:00
|
|
|
d.get("user_settings_object", False),
|
2022-10-27 19:05:10 +02:00
|
|
|
d.get("pronouns_field_type_supported", True),
|
linkifier: Support URL templates for linkifiers.
This swaps out url_format_string from all of our APIs and replaces it
with url_template. Note that the documentation changes in the following
commits will be squashed with this commit.
We change the "url_format" key to "url_template" for the
realm_linkifiers events in event_schema, along with updating
LinkifierDict. "url_template" is the name chosen to normalize
mixed usages of "url_format_string" and "url_format" throughout
the backend.
The markdown processor is updated to stop handling the format string
interpolation and delegate the task template expansion to the uri_template
library instead.
This change affects many test cases. We mostly just replace "%(name)s"
with "{name}", "url_format_string" with "url_template" to make sure that
they still pass. There are some test cases dedicated for testing "%"
escaping, which aren't relevant anymore and are subject to removal.
But for now we keep most of them as-is, and make sure that "%" is always
escaped since we do not use it for variable substitution any more.
Since url_format_string is not populated anymore, a migration is created
to remove this field entirely, and make url_template non-nullable since
we will always populate it. Note that it is possible to have
url_template being null after migration 0422 and before 0424, but
in practice, url_template will not be None after backfilling and the
backend now is always setting url_template.
With the removal of url_format_string, RealmFilter model will now be cleaned
with URL template checks, and the old checks for escapes are removed.
We also modified RealmFilter.clean to skip the validation when the
url_template is invalid. This avoids raising mulitple ValidationError's
when calling full_clean on a linkifier. But we might eventually want to
have a more centric approach to data validation instead of having
the same validation in both the clean method and the validator.
Fixes #23124.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
2022-10-05 20:55:31 +02:00
|
|
|
d.get("linkifier_url_template", False),
|
2023-10-24 19:47:39 +02:00
|
|
|
d.get("user_list_incomplete", False),
|
2024-09-12 11:46:48 +02:00
|
|
|
d.get("include_deactivated_groups", False),
|
2024-01-18 16:38:48 +01:00
|
|
|
d.get("archived_channels", False),
|
2017-10-31 18:36:18 +01:00
|
|
|
)
|
2021-02-12 08:20:45 +01:00
|
|
|
ret.last_connection_time = d["last_connection_time"]
|
2013-11-19 23:51:32 +01:00
|
|
|
return ret
|
|
|
|
|
event_queue: Fix confusing event_queue.push interface.
In e3ad9baf1d1dd862b4e3cd1aae7b3c3067d55752, we introduced yet another
bug where we incorrectly shared event dictionaries between multiple
queues.
Fortunately, the logging that reports on "event was not in the queue"
issues worked and detected this on chat.zulip.org, but this is a clear
indication that the comments we have around this system were not
sufficient to produce correct behavior.
We fix this by changing event_queue.push, the code that mutates the
event dictionaries, to do the shallow copies itself. The only
downside here is process_message_event, a relatively low-traffic code
path, does an extra per-queue dictionary copy. Given that presence,
heartbeat, and message reading events are likely more traffic and
dealing with HTTP is likely much more expensive than a dictionary
copy, this probably doesn't matter performance-wise.
(And if profiling later finds it is, there are potential workarounds
like passing a skip_copy argument we can do).
2020-02-05 20:43:09 +01:00
|
|
|
def add_event(self, event: Mapping[str, Any]) -> None:
|
2014-01-27 23:53:13 +01:00
|
|
|
if self.current_handler_id is not None:
|
|
|
|
handler = get_handler_by_id(self.current_handler_id)
|
2023-12-12 19:02:18 +01:00
|
|
|
if handler is not None:
|
|
|
|
assert handler._request is not None
|
|
|
|
async_request_timer_restart(handler._request)
|
2013-03-26 18:06:00 +01:00
|
|
|
|
|
|
|
self.event_queue.push(event)
|
2013-12-12 18:59:02 +01:00
|
|
|
self.finish_current_handler()
|
|
|
|
|
2017-11-27 11:09:23 +01:00
|
|
|
def finish_current_handler(self) -> bool:
|
2023-12-07 20:19:43 +01:00
|
|
|
if self.current_handler_id is None:
|
|
|
|
return False
|
|
|
|
try:
|
|
|
|
finish_handler(
|
|
|
|
self.current_handler_id,
|
|
|
|
self.event_queue.id,
|
|
|
|
self.event_queue.contents(),
|
|
|
|
)
|
|
|
|
except Exception:
|
|
|
|
logging.exception(
|
|
|
|
"Got error finishing handler for queue %s", self.event_queue.id, stack_info=True
|
|
|
|
)
|
|
|
|
finally:
|
|
|
|
self.disconnect_handler()
|
|
|
|
return True
|
2013-03-26 18:06:00 +01:00
|
|
|
|
2017-11-27 11:09:23 +01:00
|
|
|
def accepts_event(self, event: Mapping[str, Any]) -> bool:
|
2022-02-25 21:48:56 +01:00
|
|
|
if self.event_types is not None:
|
|
|
|
if event["type"] not in self.event_types:
|
|
|
|
return False
|
|
|
|
if event["type"] == "muted_topics" and "user_topic" in self.event_types:
|
|
|
|
# Suppress muted_topics events for clients that
|
|
|
|
# support user_topic. This allows clients to request
|
|
|
|
# both the user_topic and muted_topics event types,
|
|
|
|
# and receive the duplicate muted_topics data only on
|
|
|
|
# older servers that don't support user_topic.
|
|
|
|
return False
|
2013-12-10 16:28:16 +01:00
|
|
|
if event["type"] == "message":
|
2023-06-29 22:41:44 +02:00
|
|
|
return self.narrow_predicate(message=event["message"], flags=event["flags"])
|
2020-12-24 21:00:20 +01:00
|
|
|
if event["type"] == "typing" and "stream_id" in event:
|
|
|
|
# Typing notifications for stream messages are only
|
|
|
|
# delivered if the stream_typing_notifications
|
|
|
|
# client_capability is enabled, for backwards compatibility.
|
|
|
|
return self.stream_typing_notifications
|
2021-07-24 19:51:25 +02:00
|
|
|
if self.user_settings_object and event["type"] in [
|
|
|
|
"update_display_settings",
|
|
|
|
"update_global_notifications",
|
|
|
|
]:
|
|
|
|
# 'update_display_settings' and 'update_global_notifications'
|
|
|
|
# events are sent only if user_settings_object is False,
|
|
|
|
# otherwise only 'user_settings' event is sent.
|
|
|
|
return False
|
2024-09-12 11:46:48 +02:00
|
|
|
if event["type"] == "user_group":
|
|
|
|
if event["op"] == "remove":
|
|
|
|
# 'user_group/remove' events are only sent if the client
|
|
|
|
# cannot filter out deactivated groups by themselves.
|
|
|
|
return not self.include_deactivated_groups
|
|
|
|
if event["op"] == "update" and "deactivated" in event["data"]:
|
|
|
|
# 'update' events for group deactivation are only sent to
|
|
|
|
# clients who can filter out deactivated groups by themselves.
|
|
|
|
# Other clients receive 'remove' event.
|
|
|
|
return self.include_deactivated_groups
|
2013-12-10 16:28:16 +01:00
|
|
|
return True
|
2013-12-10 16:35:16 +01:00
|
|
|
|
|
|
|
# TODO: Refactor so we don't need this function
|
2017-11-27 11:09:23 +01:00
|
|
|
def accepts_messages(self) -> bool:
|
2013-12-10 16:35:16 +01:00
|
|
|
return self.event_types is None or "message" in self.event_types
|
2013-03-22 22:43:49 +01:00
|
|
|
|
2018-12-05 23:42:06 +01:00
|
|
|
def expired(self, now: float) -> bool:
|
2021-02-12 08:19:30 +01:00
|
|
|
return (
|
|
|
|
self.current_handler_id is None
|
|
|
|
and now - self.last_connection_time >= self.queue_timeout
|
|
|
|
)
|
2013-03-26 18:06:00 +01:00
|
|
|
|
2018-05-11 01:43:30 +02:00
|
|
|
def connect_handler(self, handler_id: int, client_name: str) -> None:
|
2014-01-27 23:53:13 +01:00
|
|
|
self.current_handler_id = handler_id
|
2014-01-28 17:17:21 +01:00
|
|
|
self.current_client_name = client_name
|
2014-01-28 17:12:18 +01:00
|
|
|
set_descriptor_by_handler_id(handler_id, self)
|
2013-03-26 18:06:00 +01:00
|
|
|
self.last_connection_time = time.time()
|
2016-11-29 07:22:02 +01:00
|
|
|
|
2017-11-27 11:09:23 +01:00
|
|
|
def timeout_callback() -> None:
|
2013-11-21 18:52:32 +01:00
|
|
|
self._timeout_handle = None
|
|
|
|
# All clients get heartbeat events
|
2021-07-02 02:13:55 +02:00
|
|
|
heartbeat_event = create_heartbeat_event()
|
|
|
|
self.add_event(heartbeat_event)
|
2021-02-12 08:19:30 +01:00
|
|
|
|
2022-03-17 21:42:25 +01:00
|
|
|
ioloop = tornado.ioloop.IOLoop.current()
|
2017-11-30 00:15:49 +01:00
|
|
|
interval = HEARTBEAT_MIN_FREQ_SECS + random.randint(0, 10)
|
2021-02-12 08:20:45 +01:00
|
|
|
if self.client_type_name != "API: heartbeat test":
|
2017-11-30 00:15:49 +01:00
|
|
|
self._timeout_handle = ioloop.call_later(interval, timeout_callback)
|
2013-03-26 18:06:00 +01:00
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
def disconnect_handler(self, client_closed: bool = False) -> None:
|
2014-01-27 23:53:13 +01:00
|
|
|
if self.current_handler_id:
|
2020-07-05 02:29:31 +02:00
|
|
|
clear_descriptor_by_handler_id(self.current_handler_id)
|
2013-12-12 19:47:24 +01:00
|
|
|
if client_closed:
|
2021-02-12 08:19:30 +01:00
|
|
|
logging.info(
|
|
|
|
"Client disconnected for queue %s (%s via %s)",
|
|
|
|
self.event_queue.id,
|
|
|
|
self.user_profile_id,
|
|
|
|
self.current_client_name,
|
|
|
|
)
|
2014-01-27 23:53:13 +01:00
|
|
|
self.current_handler_id = None
|
2014-01-28 17:17:21 +01:00
|
|
|
self.current_client_name = None
|
2016-10-19 22:26:55 +02:00
|
|
|
if self._timeout_handle is not None:
|
2022-03-17 21:42:25 +01:00
|
|
|
ioloop = tornado.ioloop.IOLoop.current()
|
2013-03-22 23:25:37 +01:00
|
|
|
ioloop.remove_timeout(self._timeout_handle)
|
|
|
|
self._timeout_handle = None
|
2013-03-26 18:06:00 +01:00
|
|
|
|
2017-11-27 11:09:23 +01:00
|
|
|
def cleanup(self) -> None:
|
2015-12-27 18:46:31 +01:00
|
|
|
# Before we can GC the event queue, we need to disconnect the
|
|
|
|
# handler and notify the client (or connection server) so that
|
docs: Add missing space to compound verbs “log in”, “set up”, etc.
Noun: backup, checkout, cleanup, login, logout, setup, shutdown, signup,
timeout.
Verb: back up, check out, clean up, log in, log out, set up, shut
down, sign up, time out.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-04-25 23:05:38 +02:00
|
|
|
# they can clean up their own state related to the GC'd event
|
2015-12-27 18:46:31 +01:00
|
|
|
# queue. Finishing the handler before we GC ensures the
|
|
|
|
# invariant that event queues are idle when passed to
|
|
|
|
# `do_gc_event_queues` is preserved.
|
2016-10-19 22:26:55 +02:00
|
|
|
self.finish_current_handler()
|
2021-02-12 08:19:30 +01:00
|
|
|
do_gc_event_queues({self.event_queue.id}, {self.user_profile_id}, {self.realm_id})
|
|
|
|
|
2013-11-19 23:11:30 +01:00
|
|
|
|
2017-11-27 11:09:23 +01:00
|
|
|
def compute_full_event_type(event: Mapping[str, Any]) -> str:
|
2013-11-22 20:30:32 +01:00
|
|
|
if event["type"] == "update_message_flags":
|
|
|
|
if event["all"]:
|
|
|
|
# Put the "all" case in its own category
|
2020-06-10 06:41:04 +02:00
|
|
|
return "all_flags/{}/{}".format(event["flag"], event["operation"])
|
|
|
|
return "flags/{}/{}".format(event["operation"], event["flag"])
|
2013-11-22 20:30:32 +01:00
|
|
|
return event["type"]
|
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
2017-11-05 11:52:10 +01:00
|
|
|
class EventQueue:
|
2017-11-27 11:09:23 +01:00
|
|
|
def __init__(self, id: str) -> None:
|
2019-08-06 00:08:56 +02:00
|
|
|
# When extending this list of properties, one must be sure to
|
|
|
|
# update to_dict and from_dict.
|
|
|
|
|
2024-07-12 02:30:17 +02:00
|
|
|
self.queue: deque[dict[str, Any]] = deque()
|
python: Convert assignment type annotations to Python 3.6 style.
This commit was split by tabbott; this piece covers the vast majority
of files in Zulip, but excludes scripts/, tools/, and puppet/ to help
ensure we at least show the right error messages for Xenial systems.
We can likely further refine the remaining pieces with some testing.
Generated by com2ann, with whitespace fixes and various manual fixes
for runtime issues:
- invoiced_through: Optional[LicenseLedger] = models.ForeignKey(
+ invoiced_through: Optional["LicenseLedger"] = models.ForeignKey(
-_apns_client: Optional[APNsClient] = None
+_apns_client: Optional["APNsClient"] = None
- notifications_stream: Optional[Stream] = models.ForeignKey('Stream', related_name='+', null=True, blank=True, on_delete=CASCADE)
- signup_notifications_stream: Optional[Stream] = models.ForeignKey('Stream', related_name='+', null=True, blank=True, on_delete=CASCADE)
+ notifications_stream: Optional["Stream"] = models.ForeignKey('Stream', related_name='+', null=True, blank=True, on_delete=CASCADE)
+ signup_notifications_stream: Optional["Stream"] = models.ForeignKey('Stream', related_name='+', null=True, blank=True, on_delete=CASCADE)
- author: Optional[UserProfile] = models.ForeignKey('UserProfile', blank=True, null=True, on_delete=CASCADE)
+ author: Optional["UserProfile"] = models.ForeignKey('UserProfile', blank=True, null=True, on_delete=CASCADE)
- bot_owner: Optional[UserProfile] = models.ForeignKey('self', null=True, on_delete=models.SET_NULL)
+ bot_owner: Optional["UserProfile"] = models.ForeignKey('self', null=True, on_delete=models.SET_NULL)
- default_sending_stream: Optional[Stream] = models.ForeignKey('zerver.Stream', null=True, related_name='+', on_delete=CASCADE)
- default_events_register_stream: Optional[Stream] = models.ForeignKey('zerver.Stream', null=True, related_name='+', on_delete=CASCADE)
+ default_sending_stream: Optional["Stream"] = models.ForeignKey('zerver.Stream', null=True, related_name='+', on_delete=CASCADE)
+ default_events_register_stream: Optional["Stream"] = models.ForeignKey('zerver.Stream', null=True, related_name='+', on_delete=CASCADE)
-descriptors_by_handler_id: Dict[int, ClientDescriptor] = {}
+descriptors_by_handler_id: Dict[int, "ClientDescriptor"] = {}
-worker_classes: Dict[str, Type[QueueProcessingWorker]] = {}
-queues: Dict[str, Dict[str, Type[QueueProcessingWorker]]] = {}
+worker_classes: Dict[str, Type["QueueProcessingWorker"]] = {}
+queues: Dict[str, Dict[str, Type["QueueProcessingWorker"]]] = {}
-AUTH_LDAP_REVERSE_EMAIL_SEARCH: Optional[LDAPSearch] = None
+AUTH_LDAP_REVERSE_EMAIL_SEARCH: Optional["LDAPSearch"] = None
Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
2020-04-22 01:09:50 +02:00
|
|
|
self.next_event_id: int = 0
|
2020-09-02 02:50:08 +02:00
|
|
|
# will only be None for migration from old versions
|
2024-07-12 02:30:23 +02:00
|
|
|
self.newest_pruned_id: int | None = -1
|
python: Convert assignment type annotations to Python 3.6 style.
This commit was split by tabbott; this piece covers the vast majority
of files in Zulip, but excludes scripts/, tools/, and puppet/ to help
ensure we at least show the right error messages for Xenial systems.
We can likely further refine the remaining pieces with some testing.
Generated by com2ann, with whitespace fixes and various manual fixes
for runtime issues:
- invoiced_through: Optional[LicenseLedger] = models.ForeignKey(
+ invoiced_through: Optional["LicenseLedger"] = models.ForeignKey(
-_apns_client: Optional[APNsClient] = None
+_apns_client: Optional["APNsClient"] = None
- notifications_stream: Optional[Stream] = models.ForeignKey('Stream', related_name='+', null=True, blank=True, on_delete=CASCADE)
- signup_notifications_stream: Optional[Stream] = models.ForeignKey('Stream', related_name='+', null=True, blank=True, on_delete=CASCADE)
+ notifications_stream: Optional["Stream"] = models.ForeignKey('Stream', related_name='+', null=True, blank=True, on_delete=CASCADE)
+ signup_notifications_stream: Optional["Stream"] = models.ForeignKey('Stream', related_name='+', null=True, blank=True, on_delete=CASCADE)
- author: Optional[UserProfile] = models.ForeignKey('UserProfile', blank=True, null=True, on_delete=CASCADE)
+ author: Optional["UserProfile"] = models.ForeignKey('UserProfile', blank=True, null=True, on_delete=CASCADE)
- bot_owner: Optional[UserProfile] = models.ForeignKey('self', null=True, on_delete=models.SET_NULL)
+ bot_owner: Optional["UserProfile"] = models.ForeignKey('self', null=True, on_delete=models.SET_NULL)
- default_sending_stream: Optional[Stream] = models.ForeignKey('zerver.Stream', null=True, related_name='+', on_delete=CASCADE)
- default_events_register_stream: Optional[Stream] = models.ForeignKey('zerver.Stream', null=True, related_name='+', on_delete=CASCADE)
+ default_sending_stream: Optional["Stream"] = models.ForeignKey('zerver.Stream', null=True, related_name='+', on_delete=CASCADE)
+ default_events_register_stream: Optional["Stream"] = models.ForeignKey('zerver.Stream', null=True, related_name='+', on_delete=CASCADE)
-descriptors_by_handler_id: Dict[int, ClientDescriptor] = {}
+descriptors_by_handler_id: Dict[int, "ClientDescriptor"] = {}
-worker_classes: Dict[str, Type[QueueProcessingWorker]] = {}
-queues: Dict[str, Dict[str, Type[QueueProcessingWorker]]] = {}
+worker_classes: Dict[str, Type["QueueProcessingWorker"]] = {}
+queues: Dict[str, Dict[str, Type["QueueProcessingWorker"]]] = {}
-AUTH_LDAP_REVERSE_EMAIL_SEARCH: Optional[LDAPSearch] = None
+AUTH_LDAP_REVERSE_EMAIL_SEARCH: Optional["LDAPSearch"] = None
Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
2020-04-22 01:09:50 +02:00
|
|
|
self.id: str = id
|
2024-07-12 02:30:17 +02:00
|
|
|
self.virtual_events: dict[str, dict[str, Any]] = {}
|
2013-03-26 18:06:00 +01:00
|
|
|
|
2024-07-12 02:30:17 +02:00
|
|
|
def to_dict(self) -> dict[str, Any]:
|
2013-11-22 20:30:32 +01:00
|
|
|
# If you add a new key to this dict, make sure you add appropriate
|
|
|
|
# migration code in from_dict or load_event_queues to account for
|
|
|
|
# loading event queues that lack that key.
|
2019-08-06 00:08:56 +02:00
|
|
|
d = dict(
|
|
|
|
id=self.id,
|
|
|
|
next_event_id=self.next_event_id,
|
|
|
|
queue=list(self.queue),
|
|
|
|
virtual_events=self.virtual_events,
|
|
|
|
)
|
|
|
|
if self.newest_pruned_id is not None:
|
2021-02-12 08:20:45 +01:00
|
|
|
d["newest_pruned_id"] = self.newest_pruned_id
|
2019-08-06 00:08:56 +02:00
|
|
|
return d
|
2013-11-19 23:51:32 +01:00
|
|
|
|
|
|
|
@classmethod
|
2024-07-12 02:30:17 +02:00
|
|
|
def from_dict(cls, d: dict[str, Any]) -> "EventQueue":
|
2021-02-12 08:20:45 +01:00
|
|
|
ret = cls(d["id"])
|
|
|
|
ret.next_event_id = d["next_event_id"]
|
2024-02-02 01:23:41 +01:00
|
|
|
ret.newest_pruned_id = d.get("newest_pruned_id")
|
2021-02-12 08:20:45 +01:00
|
|
|
ret.queue = deque(d["queue"])
|
2013-11-22 20:30:32 +01:00
|
|
|
ret.virtual_events = d.get("virtual_events", {})
|
2013-11-19 23:51:32 +01:00
|
|
|
return ret
|
|
|
|
|
event_queue: Fix confusing event_queue.push interface.
In e3ad9baf1d1dd862b4e3cd1aae7b3c3067d55752, we introduced yet another
bug where we incorrectly shared event dictionaries between multiple
queues.
Fortunately, the logging that reports on "event was not in the queue"
issues worked and detected this on chat.zulip.org, but this is a clear
indication that the comments we have around this system were not
sufficient to produce correct behavior.
We fix this by changing event_queue.push, the code that mutates the
event dictionaries, to do the shallow copies itself. The only
downside here is process_message_event, a relatively low-traffic code
path, does an extra per-queue dictionary copy. Given that presence,
heartbeat, and message reading events are likely more traffic and
dealing with HTTP is likely much more expensive than a dictionary
copy, this probably doesn't matter performance-wise.
(And if profiling later finds it is, there are potential workarounds
like passing a skip_copy argument we can do).
2020-02-05 20:43:09 +01:00
|
|
|
def push(self, orig_event: Mapping[str, Any]) -> None:
|
|
|
|
# By default, we make a shallow copy of the event dictionary
|
|
|
|
# to push into the target event queue; this allows the calling
|
|
|
|
# code to send the same "event" object to multiple queues.
|
|
|
|
# This behavior is important because the event_queue system is
|
|
|
|
# about to mutate the event dictionary, minimally to add the
|
|
|
|
# event_id attribute.
|
|
|
|
event = dict(orig_event)
|
2021-02-12 08:20:45 +01:00
|
|
|
event["id"] = self.next_event_id
|
2013-03-26 18:06:00 +01:00
|
|
|
self.next_event_id += 1
|
2013-11-22 20:30:32 +01:00
|
|
|
full_event_type = compute_full_event_type(event)
|
2024-02-09 21:29:01 +01:00
|
|
|
if full_event_type.startswith("flags/") and not full_event_type.startswith(
|
|
|
|
"flags/remove/read"
|
2022-11-17 08:19:05 +01:00
|
|
|
):
|
|
|
|
# virtual_events are an optimization that allows certain
|
|
|
|
# simple events, such as update_message_flags events that
|
|
|
|
# simply contain a list of message IDs to operate on, to
|
|
|
|
# be compressed together. This is primarily useful for
|
|
|
|
# flags/add/read, where normal Zulip usage will result in
|
|
|
|
# many small flags/add/read events as users scroll.
|
|
|
|
#
|
|
|
|
# We need to exclude flags/remove/read, because it has an
|
|
|
|
# extra message_details field that cannot be compressed.
|
|
|
|
#
|
|
|
|
# BUG: This compression algorithm is incorrect in the
|
|
|
|
# presence of mark-as-unread, since it does not respect
|
|
|
|
# the ordering of "mark as read" and "mark as unread"
|
|
|
|
# updates for a given message.
|
2013-11-22 20:30:32 +01:00
|
|
|
if full_event_type not in self.virtual_events:
|
|
|
|
self.virtual_events[full_event_type] = copy.deepcopy(event)
|
|
|
|
return
|
2022-11-17 08:19:05 +01:00
|
|
|
|
2013-11-22 20:30:32 +01:00
|
|
|
# Update the virtual event with the values from the event
|
|
|
|
virtual_event = self.virtual_events[full_event_type]
|
|
|
|
virtual_event["id"] = event["id"]
|
2024-02-09 21:29:01 +01:00
|
|
|
virtual_event["messages"] += event["messages"]
|
2013-11-22 20:30:32 +01:00
|
|
|
if "timestamp" in event:
|
|
|
|
virtual_event["timestamp"] = event["timestamp"]
|
2020-06-26 19:51:10 +02:00
|
|
|
|
2013-11-22 20:30:32 +01:00
|
|
|
else:
|
|
|
|
self.queue.append(event)
|
2013-03-26 18:06:00 +01:00
|
|
|
|
2013-12-11 23:09:59 +01:00
|
|
|
# Note that pop ignores virtual events. This is fine in our
|
|
|
|
# current usage since virtual events should always be resolved to
|
|
|
|
# a real event before being given to users.
|
2024-07-12 02:30:17 +02:00
|
|
|
def pop(self) -> dict[str, Any]:
|
2013-03-26 18:06:00 +01:00
|
|
|
return self.queue.popleft()
|
|
|
|
|
2017-11-27 11:09:23 +01:00
|
|
|
def empty(self) -> bool:
|
2013-12-11 22:58:12 +01:00
|
|
|
return len(self.queue) == 0 and len(self.virtual_events) == 0
|
2013-03-26 18:06:00 +01:00
|
|
|
|
2013-12-11 23:09:59 +01:00
|
|
|
# See the comment on pop; that applies here as well
|
2017-11-27 11:09:23 +01:00
|
|
|
def prune(self, through_id: int) -> None:
|
2021-02-12 08:20:45 +01:00
|
|
|
while len(self.queue) != 0 and self.queue[0]["id"] <= through_id:
|
|
|
|
self.newest_pruned_id = self.queue[0]["id"]
|
2013-03-26 18:06:00 +01:00
|
|
|
self.pop()
|
|
|
|
|
2024-07-12 02:30:17 +02:00
|
|
|
def contents(self, include_internal_data: bool = False) -> list[dict[str, Any]]:
|
|
|
|
contents: list[dict[str, Any]] = []
|
|
|
|
virtual_id_map: dict[str, dict[str, Any]] = {}
|
2013-11-22 20:30:32 +01:00
|
|
|
for event_type in self.virtual_events:
|
|
|
|
virtual_id_map[self.virtual_events[event_type]["id"]] = self.virtual_events[event_type]
|
2020-09-02 06:20:26 +02:00
|
|
|
virtual_ids = sorted(virtual_id_map.keys())
|
2013-11-22 20:30:32 +01:00
|
|
|
|
|
|
|
# Merge the virtual events into their final place in the queue
|
|
|
|
index = 0
|
|
|
|
length = len(virtual_ids)
|
|
|
|
for event in self.queue:
|
|
|
|
while index < length and virtual_ids[index] < event["id"]:
|
|
|
|
contents.append(virtual_id_map[virtual_ids[index]])
|
|
|
|
index += 1
|
|
|
|
contents.append(event)
|
|
|
|
while index < length:
|
|
|
|
contents.append(virtual_id_map[virtual_ids[index]])
|
|
|
|
index += 1
|
|
|
|
|
|
|
|
self.virtual_events = {}
|
|
|
|
self.queue = deque(contents)
|
2020-12-22 10:43:34 +01:00
|
|
|
|
|
|
|
if include_internal_data:
|
|
|
|
return contents
|
|
|
|
return prune_internal_data(contents)
|
|
|
|
|
|
|
|
|
2024-07-12 02:30:17 +02:00
|
|
|
def prune_internal_data(events: list[dict[str, Any]]) -> list[dict[str, Any]]:
|
2020-12-22 10:43:34 +01:00
|
|
|
"""Prunes the internal_data data structures, which are not intended to
|
|
|
|
be exposed to API clients.
|
|
|
|
"""
|
|
|
|
events = copy.deepcopy(events)
|
|
|
|
for event in events:
|
|
|
|
if event["type"] == "message" and "internal_data" in event:
|
|
|
|
del event["internal_data"]
|
|
|
|
return events
|
2013-03-26 18:06:00 +01:00
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
2024-02-07 22:03:15 +01:00
|
|
|
# Queue-ids which still need to be sent a web_reload_client event.
|
|
|
|
# This is treated as an ordered set, which is sorted by realm-id when
|
|
|
|
# loaded from disk.
|
2024-07-12 02:30:17 +02:00
|
|
|
web_reload_clients: dict[str, Literal[True]] = {}
|
2024-02-07 22:03:15 +01:00
|
|
|
|
2013-03-26 18:06:00 +01:00
|
|
|
# maps queue ids to client descriptors
|
2024-07-12 02:30:17 +02:00
|
|
|
clients: dict[str, ClientDescriptor] = {}
|
2013-03-26 18:06:00 +01:00
|
|
|
# maps user id to list of client descriptors
|
2024-07-12 02:30:17 +02:00
|
|
|
user_clients: dict[int, list[ClientDescriptor]] = {}
|
2013-10-17 23:51:25 +02:00
|
|
|
# maps realm id to list of client descriptors with all_public_streams=True
|
2024-07-12 02:30:17 +02:00
|
|
|
realm_clients_all_streams: dict[int, list[ClientDescriptor]] = {}
|
2013-03-26 18:06:00 +01:00
|
|
|
|
2013-05-22 23:49:02 +02:00
|
|
|
# list of registered gc hooks.
|
|
|
|
# each one will be called with a user profile id, queue, and bool
|
|
|
|
# last_for_client that is true if this is the last queue pertaining
|
|
|
|
# to this user_profile_id
|
|
|
|
# that is about to be deleted
|
2024-07-12 02:30:17 +02:00
|
|
|
gc_hooks: list[Callable[[int, ClientDescriptor, bool], None]] = []
|
2013-05-22 23:49:02 +02:00
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
2017-11-27 11:09:23 +01:00
|
|
|
def clear_client_event_queues_for_testing() -> None:
|
2021-02-12 08:19:30 +01:00
|
|
|
assert settings.TEST_SUITE
|
2017-10-12 01:37:44 +02:00
|
|
|
clients.clear()
|
2024-02-07 22:03:15 +01:00
|
|
|
web_reload_clients.clear()
|
2017-10-12 01:37:44 +02:00
|
|
|
user_clients.clear()
|
|
|
|
realm_clients_all_streams.clear()
|
|
|
|
gc_hooks.clear()
|
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
2017-11-27 11:09:23 +01:00
|
|
|
def add_client_gc_hook(hook: Callable[[int, ClientDescriptor, bool], None]) -> None:
|
2013-05-22 23:49:02 +02:00
|
|
|
gc_hooks.append(hook)
|
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
2022-09-17 21:55:15 +02:00
|
|
|
def access_client_descriptor(user_id: int, queue_id: str) -> ClientDescriptor:
|
|
|
|
client = clients.get(queue_id)
|
|
|
|
if client is not None:
|
|
|
|
if user_id == client.user_profile_id:
|
|
|
|
return client
|
|
|
|
logging.warning(
|
|
|
|
"User %d is not authorized for queue %s (%d via %s)",
|
|
|
|
user_id,
|
|
|
|
queue_id,
|
|
|
|
client.user_profile_id,
|
|
|
|
client.current_client_name,
|
|
|
|
)
|
|
|
|
raise BadEventQueueIdError(queue_id)
|
2013-03-27 22:19:24 +01:00
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
2024-07-12 02:30:17 +02:00
|
|
|
def get_client_descriptors_for_user(user_profile_id: int) -> list[ClientDescriptor]:
|
2013-03-27 22:19:24 +01:00
|
|
|
return user_clients.get(user_profile_id, [])
|
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
2024-07-12 02:30:17 +02:00
|
|
|
def get_client_descriptors_for_realm_all_streams(realm_id: int) -> list[ClientDescriptor]:
|
2013-10-17 23:51:25 +02:00
|
|
|
return realm_clients_all_streams.get(realm_id, [])
|
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
2017-11-27 11:09:23 +01:00
|
|
|
def add_to_client_dicts(client: ClientDescriptor) -> None:
|
2013-12-13 20:59:56 +01:00
|
|
|
user_clients.setdefault(client.user_profile_id, []).append(client)
|
2013-12-13 20:20:28 +01:00
|
|
|
if client.all_public_streams or client.narrow != []:
|
2013-12-13 20:59:56 +01:00
|
|
|
realm_clients_all_streams.setdefault(client.realm_id, []).append(client)
|
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
2017-11-27 11:09:23 +01:00
|
|
|
def allocate_client_descriptor(new_queue_data: MutableMapping[str, Any]) -> ClientDescriptor:
|
2022-09-16 03:48:59 +02:00
|
|
|
queue_id = str(uuid.uuid4())
|
2014-01-28 18:11:08 +01:00
|
|
|
new_queue_data["event_queue"] = EventQueue(queue_id).to_dict()
|
|
|
|
client = ClientDescriptor.from_dict(new_queue_data)
|
|
|
|
clients[queue_id] = client
|
2013-12-13 20:59:56 +01:00
|
|
|
add_to_client_dicts(client)
|
2013-03-26 18:06:00 +01:00
|
|
|
return client
|
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
|
|
|
def do_gc_event_queues(
|
|
|
|
to_remove: AbstractSet[str], affected_users: AbstractSet[int], affected_realms: AbstractSet[int]
|
|
|
|
) -> None:
|
|
|
|
def filter_client_dict(
|
2024-07-12 02:30:17 +02:00
|
|
|
client_dict: MutableMapping[int, list[ClientDescriptor]], key: int
|
2021-02-12 08:19:30 +01:00
|
|
|
) -> None:
|
2013-10-17 23:51:25 +02:00
|
|
|
if key not in client_dict:
|
|
|
|
return
|
2013-03-26 18:06:00 +01:00
|
|
|
|
2015-11-01 17:14:31 +01:00
|
|
|
new_client_list = [c for c in client_dict[key] if c.event_queue.id not in to_remove]
|
2013-04-09 19:24:55 +02:00
|
|
|
if len(new_client_list) == 0:
|
2013-10-17 23:51:25 +02:00
|
|
|
del client_dict[key]
|
2013-04-09 19:24:55 +02:00
|
|
|
else:
|
2013-10-17 23:51:25 +02:00
|
|
|
client_dict[key] = new_client_list
|
|
|
|
|
|
|
|
for user_id in affected_users:
|
|
|
|
filter_client_dict(user_clients, user_id)
|
|
|
|
|
|
|
|
for realm_id in affected_realms:
|
|
|
|
filter_client_dict(realm_clients_all_streams, realm_id)
|
2013-03-26 18:06:00 +01:00
|
|
|
|
2013-05-22 23:49:02 +02:00
|
|
|
for id in to_remove:
|
2024-02-07 22:03:15 +01:00
|
|
|
if id in web_reload_clients:
|
|
|
|
del web_reload_clients[id]
|
2013-05-22 23:49:02 +02:00
|
|
|
for cb in gc_hooks:
|
2021-02-12 08:19:30 +01:00
|
|
|
cb(
|
|
|
|
clients[id].user_profile_id,
|
|
|
|
clients[id],
|
|
|
|
clients[id].user_profile_id not in user_clients,
|
|
|
|
)
|
2013-05-22 23:49:02 +02:00
|
|
|
del clients[id]
|
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
2018-10-04 00:22:39 +02:00
|
|
|
def gc_event_queues(port: int) -> None:
|
2024-02-21 06:44:27 +01:00
|
|
|
# We cannot use perf_counter here, since we store and compare UNIX
|
|
|
|
# timestamps to it in the queues.
|
|
|
|
start = time.time()
|
2024-07-12 02:30:17 +02:00
|
|
|
to_remove: set[str] = set()
|
|
|
|
affected_users: set[int] = set()
|
|
|
|
affected_realms: set[int] = set()
|
2023-02-02 04:35:24 +01:00
|
|
|
for id, client in clients.items():
|
2018-12-05 23:42:06 +01:00
|
|
|
if client.expired(start):
|
2013-11-19 23:11:30 +01:00
|
|
|
to_remove.add(id)
|
|
|
|
affected_users.add(client.user_profile_id)
|
|
|
|
affected_realms.add(client.realm_id)
|
|
|
|
|
2015-12-27 18:46:31 +01:00
|
|
|
# We don't need to call e.g. finish_current_handler on the clients
|
2018-12-05 23:42:06 +01:00
|
|
|
# being removed because they are guaranteed to be idle (because
|
|
|
|
# they are expired) and thus not have a current handler.
|
2013-11-19 23:11:30 +01:00
|
|
|
do_gc_event_queues(to_remove, affected_users, affected_realms)
|
|
|
|
|
2017-09-14 20:52:40 +02:00
|
|
|
if settings.PRODUCTION:
|
2021-02-12 08:19:30 +01:00
|
|
|
logging.info(
|
2021-02-12 08:20:45 +01:00
|
|
|
"Tornado %d removed %d expired event queues owned by %d users in %.3fs."
|
|
|
|
" Now %d active queues, %s",
|
2021-02-12 08:19:30 +01:00
|
|
|
port,
|
|
|
|
len(to_remove),
|
|
|
|
len(affected_users),
|
2024-02-21 06:44:27 +01:00
|
|
|
time.time() - start,
|
2021-02-12 08:19:30 +01:00
|
|
|
len(clients),
|
|
|
|
handler_stats_string(),
|
|
|
|
)
|
2013-03-26 18:06:00 +01:00
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
|
|
|
def persistent_queue_filename(port: int, last: bool = False) -> str:
|
2018-10-04 00:22:39 +02:00
|
|
|
if settings.TORNADO_PROCESSES == 1:
|
|
|
|
# Use non-port-aware, legacy version.
|
|
|
|
if last:
|
2021-02-12 08:20:45 +01:00
|
|
|
return settings.JSON_PERSISTENT_QUEUE_FILENAME_PATTERN % ("",) + ".last"
|
|
|
|
return settings.JSON_PERSISTENT_QUEUE_FILENAME_PATTERN % ("",)
|
2018-10-04 00:14:16 +02:00
|
|
|
if last:
|
2021-02-12 08:20:45 +01:00
|
|
|
return settings.JSON_PERSISTENT_QUEUE_FILENAME_PATTERN % ("." + str(port) + ".last",)
|
|
|
|
return settings.JSON_PERSISTENT_QUEUE_FILENAME_PATTERN % ("." + str(port),)
|
2018-10-04 00:14:16 +02:00
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
2018-10-04 00:22:39 +02:00
|
|
|
def dump_event_queues(port: int) -> None:
|
2024-02-07 21:52:17 +01:00
|
|
|
start = time.perf_counter()
|
2013-03-20 23:03:41 +01:00
|
|
|
|
2020-08-07 01:09:47 +02:00
|
|
|
with open(persistent_queue_filename(port), "wb") as stored_queues:
|
|
|
|
stored_queues.write(
|
|
|
|
orjson.dumps([(qid, client.to_dict()) for (qid, client) in clients.items()])
|
|
|
|
)
|
2013-03-20 23:03:41 +01:00
|
|
|
|
2020-12-20 21:13:34 +01:00
|
|
|
if len(clients) > 0 or settings.PRODUCTION:
|
2021-02-12 08:19:30 +01:00
|
|
|
logging.info(
|
2024-02-07 21:52:17 +01:00
|
|
|
"Tornado %d dumped %d event queues in %.3fs",
|
|
|
|
port,
|
|
|
|
len(clients),
|
|
|
|
time.perf_counter() - start,
|
2021-02-12 08:19:30 +01:00
|
|
|
)
|
|
|
|
|
2013-03-20 23:03:41 +01:00
|
|
|
|
2018-10-04 00:22:39 +02:00
|
|
|
def load_event_queues(port: int) -> None:
|
2013-03-20 23:03:41 +01:00
|
|
|
global clients
|
2024-02-07 21:52:17 +01:00
|
|
|
start = time.perf_counter()
|
2013-11-19 23:51:32 +01:00
|
|
|
|
2014-01-28 19:07:45 +01:00
|
|
|
try:
|
2020-08-07 01:09:47 +02:00
|
|
|
with open(persistent_queue_filename(port), "rb") as stored_queues:
|
|
|
|
data = orjson.loads(stored_queues.read())
|
2020-03-20 02:12:02 +01:00
|
|
|
except FileNotFoundError:
|
|
|
|
pass
|
2020-08-12 20:23:23 +02:00
|
|
|
except orjson.JSONDecodeError:
|
2020-08-11 03:19:00 +02:00
|
|
|
logging.exception("Tornado %d could not deserialize event queues", port, stack_info=True)
|
2020-03-20 02:12:02 +01:00
|
|
|
else:
|
2013-11-19 23:51:32 +01:00
|
|
|
try:
|
2021-02-12 08:19:30 +01:00
|
|
|
clients = {qid: ClientDescriptor.from_dict(client) for (qid, client) in data}
|
2014-01-28 19:07:45 +01:00
|
|
|
except Exception:
|
2021-02-12 08:19:30 +01:00
|
|
|
logging.exception(
|
|
|
|
"Tornado %d could not deserialize event queues", port, stack_info=True
|
|
|
|
)
|
2013-03-20 23:03:41 +01:00
|
|
|
|
2024-02-07 22:03:15 +01:00
|
|
|
mark_clients_to_reload(clients.keys())
|
|
|
|
|
2017-09-27 10:09:12 +02:00
|
|
|
for client in clients.values():
|
2013-11-19 23:25:59 +01:00
|
|
|
# Put code for migrations due to event queue data format changes here
|
2013-10-17 23:51:25 +02:00
|
|
|
|
2013-12-13 20:59:56 +01:00
|
|
|
add_to_client_dicts(client)
|
2013-03-20 23:03:41 +01:00
|
|
|
|
2020-12-20 21:13:34 +01:00
|
|
|
if len(clients) > 0 or settings.PRODUCTION:
|
2021-02-12 08:19:30 +01:00
|
|
|
logging.info(
|
2024-02-07 21:52:17 +01:00
|
|
|
"Tornado %d loaded %d event queues in %.3fs",
|
|
|
|
port,
|
|
|
|
len(clients),
|
|
|
|
time.perf_counter() - start,
|
2021-02-12 08:19:30 +01:00
|
|
|
)
|
2013-03-20 23:03:41 +01:00
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
2024-02-10 04:19:08 +01:00
|
|
|
def send_restart_events() -> None:
|
2024-07-12 02:30:17 +02:00
|
|
|
event: dict[str, Any] = dict(
|
2021-04-18 11:28:39 +02:00
|
|
|
type="restart",
|
|
|
|
zulip_version=ZULIP_VERSION,
|
2021-07-30 12:25:53 +02:00
|
|
|
zulip_merge_base=ZULIP_MERGE_BASE,
|
2021-04-18 11:28:39 +02:00
|
|
|
zulip_feature_level=API_FEATURE_LEVEL,
|
|
|
|
server_generation=settings.SERVER_GENERATION,
|
|
|
|
)
|
2024-02-10 04:19:08 +01:00
|
|
|
for client in clients.values():
|
|
|
|
if client.accepts_event(event):
|
|
|
|
client.add_event(event)
|
|
|
|
|
|
|
|
|
2024-02-07 22:03:15 +01:00
|
|
|
def mark_clients_to_reload(queue_ids: Iterable[str]) -> None:
|
|
|
|
# Build web_reload_clients, which is a sorted-by-realm-id list of
|
|
|
|
# website client queue-ids which were were loaded from old Tornado
|
|
|
|
# instances. We use an (ordered) dict to make removing one be
|
|
|
|
# O(1), as well as pulling an ordered N of them to be O(N). We
|
|
|
|
# sort by realm_id so that restarts are rolling by realm.
|
|
|
|
for qid in sorted(
|
|
|
|
(qid for qid in queue_ids if clients[qid].accepts_event({"type": "web_reload_client"})),
|
|
|
|
key=lambda qid: clients[qid].realm_id,
|
|
|
|
):
|
|
|
|
web_reload_clients[qid] = True
|
|
|
|
|
|
|
|
|
2024-07-12 02:30:23 +02:00
|
|
|
def send_web_reload_client_events(immediate: bool = False, count: int | None = None) -> int:
|
2024-07-12 02:30:17 +02:00
|
|
|
event: dict[str, Any] = dict(
|
2024-02-10 04:19:08 +01:00
|
|
|
type="web_reload_client",
|
|
|
|
immediate=immediate,
|
|
|
|
)
|
2024-02-07 22:03:15 +01:00
|
|
|
if count is None:
|
|
|
|
count = len(web_reload_clients)
|
|
|
|
queue_ids = list(web_reload_clients.keys())[:count]
|
|
|
|
for qid in queue_ids:
|
|
|
|
del web_reload_clients[qid]
|
|
|
|
client = clients[qid]
|
2013-12-10 16:35:16 +01:00
|
|
|
if client.accepts_event(event):
|
event_queue: Fix confusing event_queue.push interface.
In e3ad9baf1d1dd862b4e3cd1aae7b3c3067d55752, we introduced yet another
bug where we incorrectly shared event dictionaries between multiple
queues.
Fortunately, the logging that reports on "event was not in the queue"
issues worked and detected this on chat.zulip.org, but this is a clear
indication that the comments we have around this system were not
sufficient to produce correct behavior.
We fix this by changing event_queue.push, the code that mutates the
event dictionaries, to do the shallow copies itself. The only
downside here is process_message_event, a relatively low-traffic code
path, does an extra per-queue dictionary copy. Given that presence,
heartbeat, and message reading events are likely more traffic and
dealing with HTTP is likely much more expensive than a dictionary
copy, this probably doesn't matter performance-wise.
(And if profiling later finds it is, there are potential workarounds
like passing a skip_copy argument we can do).
2020-02-05 20:43:09 +01:00
|
|
|
client.add_event(event)
|
2024-02-08 20:57:16 +01:00
|
|
|
return len(queue_ids)
|
2013-03-20 23:53:46 +01:00
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
2024-02-08 21:20:44 +01:00
|
|
|
async def setup_event_queue(
|
|
|
|
server: tornado.httpserver.HTTPServer, port: int, send_reloads: bool = True
|
|
|
|
) -> None:
|
2016-04-13 04:28:49 +02:00
|
|
|
if not settings.TEST_SUITE:
|
2018-10-04 00:22:39 +02:00
|
|
|
load_event_queues(port)
|
2022-03-17 22:09:11 +01:00
|
|
|
autoreload.add_reload_hook(lambda: dump_event_queues(port))
|
2013-03-20 23:03:41 +01:00
|
|
|
|
2023-01-18 05:25:49 +01:00
|
|
|
with suppress(OSError):
|
2018-10-04 00:22:39 +02:00
|
|
|
os.rename(persistent_queue_filename(port), persistent_queue_filename(port, last=True))
|
2013-11-19 23:51:32 +01:00
|
|
|
|
2013-03-20 23:03:41 +01:00
|
|
|
# Set up event queue garbage collection
|
2022-03-17 21:42:25 +01:00
|
|
|
pc = tornado.ioloop.PeriodicCallback(lambda: gc_event_queues(port), EVENT_QUEUE_GC_FREQ_MSECS)
|
2013-03-26 18:06:00 +01:00
|
|
|
pc.start()
|
2013-03-14 23:21:53 +01:00
|
|
|
|
2024-02-10 04:19:08 +01:00
|
|
|
send_restart_events()
|
2024-02-08 21:20:44 +01:00
|
|
|
if send_reloads:
|
|
|
|
send_web_reload_client_events(immediate=settings.DEVELOPMENT)
|
2013-03-20 23:53:46 +01:00
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
2022-06-24 10:03:36 +02:00
|
|
|
def fetch_events(
|
2024-07-12 02:30:23 +02:00
|
|
|
queue_id: str | None,
|
2022-06-24 10:03:36 +02:00
|
|
|
dont_block: bool,
|
2024-07-12 02:30:23 +02:00
|
|
|
last_event_id: int | None,
|
2022-06-24 10:03:36 +02:00
|
|
|
user_profile_id: int,
|
2024-07-12 02:30:23 +02:00
|
|
|
new_queue_data: MutableMapping[str, Any] | None,
|
2022-06-24 10:03:36 +02:00
|
|
|
client_type_name: str,
|
|
|
|
handler_id: int,
|
2024-07-12 02:30:17 +02:00
|
|
|
) -> dict[str, Any]:
|
2015-12-27 20:36:20 +01:00
|
|
|
try:
|
|
|
|
was_connected = False
|
|
|
|
orig_queue_id = queue_id
|
|
|
|
extra_log_data = ""
|
|
|
|
if queue_id is None:
|
|
|
|
if dont_block:
|
2020-07-05 02:29:31 +02:00
|
|
|
assert new_queue_data is not None
|
2015-12-27 20:36:20 +01:00
|
|
|
client = allocate_client_descriptor(new_queue_data)
|
|
|
|
queue_id = client.event_queue.id
|
|
|
|
else:
|
2016-05-25 15:02:02 +02:00
|
|
|
raise JsonableError(_("Missing 'queue_id' argument"))
|
2014-01-27 23:21:39 +01:00
|
|
|
else:
|
2015-12-27 20:36:20 +01:00
|
|
|
if last_event_id is None:
|
2016-05-25 15:02:02 +02:00
|
|
|
raise JsonableError(_("Missing 'last_event_id' argument"))
|
2022-09-17 21:55:15 +02:00
|
|
|
client = access_client_descriptor(user_profile_id, queue_id)
|
2019-08-06 00:08:56 +02:00
|
|
|
if (
|
|
|
|
client.event_queue.newest_pruned_id is not None
|
|
|
|
and last_event_id < client.event_queue.newest_pruned_id
|
|
|
|
):
|
2021-02-12 08:19:30 +01:00
|
|
|
raise JsonableError(
|
|
|
|
_("An event newer than {event_id} has already been pruned!").format(
|
|
|
|
event_id=last_event_id,
|
|
|
|
)
|
|
|
|
)
|
2015-12-27 20:36:20 +01:00
|
|
|
client.event_queue.prune(last_event_id)
|
2019-08-06 00:08:56 +02:00
|
|
|
if (
|
|
|
|
client.event_queue.newest_pruned_id is not None
|
|
|
|
and last_event_id != client.event_queue.newest_pruned_id
|
|
|
|
):
|
2021-02-12 08:19:30 +01:00
|
|
|
raise JsonableError(
|
|
|
|
_("Event {event_id} was not in this queue").format(
|
|
|
|
event_id=last_event_id,
|
|
|
|
)
|
|
|
|
)
|
2015-12-27 20:36:20 +01:00
|
|
|
was_connected = client.finish_current_handler()
|
|
|
|
|
|
|
|
if not client.event_queue.empty() or dont_block:
|
2024-07-12 02:30:17 +02:00
|
|
|
response: dict[str, Any] = dict(
|
python: Convert assignment type annotations to Python 3.6 style.
This commit was split by tabbott; this piece covers the vast majority
of files in Zulip, but excludes scripts/, tools/, and puppet/ to help
ensure we at least show the right error messages for Xenial systems.
We can likely further refine the remaining pieces with some testing.
Generated by com2ann, with whitespace fixes and various manual fixes
for runtime issues:
- invoiced_through: Optional[LicenseLedger] = models.ForeignKey(
+ invoiced_through: Optional["LicenseLedger"] = models.ForeignKey(
-_apns_client: Optional[APNsClient] = None
+_apns_client: Optional["APNsClient"] = None
- notifications_stream: Optional[Stream] = models.ForeignKey('Stream', related_name='+', null=True, blank=True, on_delete=CASCADE)
- signup_notifications_stream: Optional[Stream] = models.ForeignKey('Stream', related_name='+', null=True, blank=True, on_delete=CASCADE)
+ notifications_stream: Optional["Stream"] = models.ForeignKey('Stream', related_name='+', null=True, blank=True, on_delete=CASCADE)
+ signup_notifications_stream: Optional["Stream"] = models.ForeignKey('Stream', related_name='+', null=True, blank=True, on_delete=CASCADE)
- author: Optional[UserProfile] = models.ForeignKey('UserProfile', blank=True, null=True, on_delete=CASCADE)
+ author: Optional["UserProfile"] = models.ForeignKey('UserProfile', blank=True, null=True, on_delete=CASCADE)
- bot_owner: Optional[UserProfile] = models.ForeignKey('self', null=True, on_delete=models.SET_NULL)
+ bot_owner: Optional["UserProfile"] = models.ForeignKey('self', null=True, on_delete=models.SET_NULL)
- default_sending_stream: Optional[Stream] = models.ForeignKey('zerver.Stream', null=True, related_name='+', on_delete=CASCADE)
- default_events_register_stream: Optional[Stream] = models.ForeignKey('zerver.Stream', null=True, related_name='+', on_delete=CASCADE)
+ default_sending_stream: Optional["Stream"] = models.ForeignKey('zerver.Stream', null=True, related_name='+', on_delete=CASCADE)
+ default_events_register_stream: Optional["Stream"] = models.ForeignKey('zerver.Stream', null=True, related_name='+', on_delete=CASCADE)
-descriptors_by_handler_id: Dict[int, ClientDescriptor] = {}
+descriptors_by_handler_id: Dict[int, "ClientDescriptor"] = {}
-worker_classes: Dict[str, Type[QueueProcessingWorker]] = {}
-queues: Dict[str, Dict[str, Type[QueueProcessingWorker]]] = {}
+worker_classes: Dict[str, Type["QueueProcessingWorker"]] = {}
+queues: Dict[str, Dict[str, Type["QueueProcessingWorker"]]] = {}
-AUTH_LDAP_REVERSE_EMAIL_SEARCH: Optional[LDAPSearch] = None
+AUTH_LDAP_REVERSE_EMAIL_SEARCH: Optional["LDAPSearch"] = None
Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
2020-04-22 01:09:50 +02:00
|
|
|
events=client.event_queue.contents(),
|
|
|
|
)
|
2015-12-27 20:36:20 +01:00
|
|
|
if orig_queue_id is None:
|
2021-02-12 08:20:45 +01:00
|
|
|
response["queue_id"] = queue_id
|
2016-10-19 22:14:52 +02:00
|
|
|
if len(response["events"]) == 1:
|
2021-02-12 08:19:30 +01:00
|
|
|
extra_log_data = "[{}/{}/{}]".format(
|
|
|
|
queue_id, len(response["events"]), response["events"][0]["type"]
|
|
|
|
)
|
2016-10-19 22:14:52 +02:00
|
|
|
else:
|
2020-06-10 06:41:04 +02:00
|
|
|
extra_log_data = "[{}/{}]".format(queue_id, len(response["events"]))
|
2015-12-27 20:36:20 +01:00
|
|
|
if was_connected:
|
|
|
|
extra_log_data += " [was connected]"
|
2014-01-28 20:03:05 +01:00
|
|
|
return dict(type="response", response=response, extra_log_data=extra_log_data)
|
2015-12-27 20:36:20 +01:00
|
|
|
|
|
|
|
# After this point, dont_block=False, the queue is empty, and we
|
|
|
|
# have a pre-existing queue, so we wait for new events.
|
2014-01-27 23:21:39 +01:00
|
|
|
if was_connected:
|
2021-02-12 08:19:30 +01:00
|
|
|
logging.info(
|
|
|
|
"Disconnected handler for queue %s (%s/%s)",
|
|
|
|
queue_id,
|
|
|
|
user_profile_id,
|
|
|
|
client_type_name,
|
|
|
|
)
|
2015-12-27 20:36:20 +01:00
|
|
|
except JsonableError as e:
|
2017-07-21 02:32:52 +02:00
|
|
|
return dict(type="error", exception=e)
|
2015-12-27 20:36:20 +01:00
|
|
|
|
2014-01-28 18:13:41 +01:00
|
|
|
client.connect_handler(handler_id, client_type_name)
|
2014-01-28 20:03:05 +01:00
|
|
|
return dict(type="async")
|
2014-01-27 23:21:39 +01:00
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
2024-07-12 02:30:17 +02:00
|
|
|
def build_offline_notification(user_profile_id: int, message_id: int) -> dict[str, Any]:
|
2021-02-12 08:19:30 +01:00
|
|
|
return {
|
|
|
|
"user_profile_id": user_profile_id,
|
|
|
|
"message_id": message_id,
|
|
|
|
}
|
|
|
|
|
2014-04-24 02:16:53 +02:00
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
def missedmessage_hook(
|
|
|
|
user_profile_id: int, client: ClientDescriptor, last_for_client: bool
|
|
|
|
) -> None:
|
2017-10-03 19:54:54 +02:00
|
|
|
"""The receiver_is_off_zulip logic used to determine whether a user
|
|
|
|
has no active client suffers from a somewhat fundamental race
|
|
|
|
condition. If the client is no longer on the Internet,
|
2021-03-03 19:01:28 +01:00
|
|
|
receiver_is_off_zulip will still return False for
|
2018-12-05 23:48:40 +01:00
|
|
|
DEFAULT_EVENT_QUEUE_TIMEOUT_SECS, until the queue is
|
2017-10-03 19:54:54 +02:00
|
|
|
garbage-collected. This would cause us to reliably miss
|
|
|
|
push/email notifying users for messages arriving during the
|
2018-12-05 23:48:40 +01:00
|
|
|
DEFAULT_EVENT_QUEUE_TIMEOUT_SECS after they suspend their laptop (for
|
2017-10-03 19:54:54 +02:00
|
|
|
example). We address this by, when the queue is garbage-collected
|
|
|
|
at the end of those 10 minutes, checking to see if it's the last
|
|
|
|
one, and if so, potentially triggering notifications to the user
|
2018-12-05 23:48:40 +01:00
|
|
|
at that time, resulting in at most a DEFAULT_EVENT_QUEUE_TIMEOUT_SECS
|
2017-10-03 19:54:54 +02:00
|
|
|
delay in the arrival of their notifications.
|
|
|
|
|
|
|
|
As Zulip's APIs get more popular and the mobile apps start using
|
|
|
|
long-lived event queues for perf optimization, future versions of
|
|
|
|
this will likely need to replace checking `last_for_client` with
|
|
|
|
something more complicated, so that we only consider clients like
|
|
|
|
web browsers, not the mobile apps or random API scripts.
|
|
|
|
"""
|
2014-04-24 02:16:53 +02:00
|
|
|
# Only process missedmessage hook when the last queue for a
|
|
|
|
# client has been garbage collected
|
|
|
|
if not last_for_client:
|
|
|
|
return
|
|
|
|
|
2020-12-22 10:43:34 +01:00
|
|
|
for event in client.event_queue.contents(include_internal_data=True):
|
2021-02-12 08:20:45 +01:00
|
|
|
if event["type"] != "message":
|
2014-04-24 02:16:53 +02:00
|
|
|
continue
|
2021-06-11 14:27:00 +02:00
|
|
|
internal_data = event.get("internal_data", {})
|
maybe_enqueue_notifications: Take in notification_data dataclass.
* Modify `maybe_enqueue_notifications` to take in an instance of the
dataclass introduced in 951b49c048ba3464e74ad7965da3453fe36d0a96.
* The `check_notify` tests tested the "when to notify" logic in a way
which involved `maybe_enqueue_notifications`. To simplify things, we've
earlier extracted this logic in 8182632d7e9f8490b9b9295e01b5912dcf173fd5.
So, we just kill off the `check_notify` test, and keep only those parts
which verify the queueing and return value behavior of that funtion.
* We retain the the missedmessage_hook and message
message_edit_notifications since they are more integration-style.
* There's a slightly subtle change with the missedmessage_hook tests.
Before this commit, we short-circuited the hook if the sender was muted
(5a642cea115be159175d1189f83ba25d2c5c7632).
With this commit, we delegate the check to our dataclass methods.
So, `maybe_enqueue_notifications` will be called even if the sender was
muted, and the test needs to be updated.
* In our test helper `get_maybe_enqueue_notifications_parameters` which
generates default values for testing `maybe_enqueue_notifications` calls,
we keep `message_id`, `sender_id`, and `user_id` as required arguments,
so that the tests are super-clear and avoid accidental false positives.
* Because `do_update_embedded_data` also sends `update_message` events,
we deal with that case with some hacky code for now. See the comment
there.
This mostly completes the extraction of the "when to notify" logic into
our new `notification_data` module.
2021-06-23 14:12:32 +02:00
|
|
|
sender_id = event["message"]["sender_id"]
|
2021-06-11 14:27:00 +02:00
|
|
|
|
2023-08-04 22:08:17 +02:00
|
|
|
# TODO/compatibility: Translation code for the rename of
|
|
|
|
# `pm_push_notify` to `dm_push_notify`. Remove this when
|
|
|
|
# one can no longer directly upgrade from 7.x to main.
|
|
|
|
dm_push_notify = False
|
|
|
|
if "dm_push_notify" in internal_data:
|
|
|
|
dm_push_notify = internal_data.get("dm_push_notify")
|
|
|
|
elif "pm_push_notify" in internal_data:
|
|
|
|
dm_push_notify = internal_data.get("pm_push_notify")
|
|
|
|
|
|
|
|
# TODO/compatibility: Translation code for the rename of
|
|
|
|
# `pm_email_notify` to `dm_email_notify`. Remove this when
|
|
|
|
# one can no longer directly upgrade from 7.x to main.
|
|
|
|
dm_email_notify = False
|
|
|
|
if "dm_email_notify" in internal_data:
|
|
|
|
dm_email_notify = internal_data.get("dm_email_notify")
|
|
|
|
elif "pm_email_notify" in internal_data:
|
|
|
|
dm_email_notify = internal_data.get("pm_email_notify")
|
|
|
|
|
2023-06-03 16:51:38 +02:00
|
|
|
# TODO/compatibility: Translation code for the rename of
|
|
|
|
# `wildcard_mention_push_notify` to `stream_wildcard_mention_push_notify`.
|
|
|
|
# Remove this when one can no longer directly upgrade from 7.x to main.
|
|
|
|
stream_wildcard_mention_push_notify = False
|
|
|
|
if "stream_wildcard_mention_push_notify" in internal_data:
|
|
|
|
stream_wildcard_mention_push_notify = internal_data.get(
|
|
|
|
"stream_wildcard_mention_push_notify"
|
|
|
|
)
|
|
|
|
elif "wildcard_mention_push_notify" in internal_data:
|
|
|
|
stream_wildcard_mention_push_notify = internal_data.get("wildcard_mention_push_notify")
|
|
|
|
|
|
|
|
# TODO/compatibility: Translation code for the rename of
|
|
|
|
# `wildcard_mention_email_notify` to `stream_wildcard_mention_email_notify`.
|
|
|
|
# Remove this when one can no longer directly upgrade from 7.x to main.
|
|
|
|
stream_wildcard_mention_email_notify = False
|
|
|
|
if "stream_wildcard_mention_email_notify" in internal_data:
|
|
|
|
stream_wildcard_mention_email_notify = internal_data.get(
|
|
|
|
"stream_wildcard_mention_email_notify"
|
|
|
|
)
|
|
|
|
elif "wildcard_mention_email_notify" in internal_data:
|
|
|
|
stream_wildcard_mention_email_notify = internal_data.get(
|
|
|
|
"wildcard_mention_email_notify"
|
|
|
|
)
|
|
|
|
|
maybe_enqueue_notifications: Take in notification_data dataclass.
* Modify `maybe_enqueue_notifications` to take in an instance of the
dataclass introduced in 951b49c048ba3464e74ad7965da3453fe36d0a96.
* The `check_notify` tests tested the "when to notify" logic in a way
which involved `maybe_enqueue_notifications`. To simplify things, we've
earlier extracted this logic in 8182632d7e9f8490b9b9295e01b5912dcf173fd5.
So, we just kill off the `check_notify` test, and keep only those parts
which verify the queueing and return value behavior of that funtion.
* We retain the the missedmessage_hook and message
message_edit_notifications since they are more integration-style.
* There's a slightly subtle change with the missedmessage_hook tests.
Before this commit, we short-circuited the hook if the sender was muted
(5a642cea115be159175d1189f83ba25d2c5c7632).
With this commit, we delegate the check to our dataclass methods.
So, `maybe_enqueue_notifications` will be called even if the sender was
muted, and the test needs to be updated.
* In our test helper `get_maybe_enqueue_notifications_parameters` which
generates default values for testing `maybe_enqueue_notifications` calls,
we keep `message_id`, `sender_id`, and `user_id` as required arguments,
so that the tests are super-clear and avoid accidental false positives.
* Because `do_update_embedded_data` also sends `update_message` events,
we deal with that case with some hacky code for now. See the comment
there.
This mostly completes the extraction of the "when to notify" logic into
our new `notification_data` module.
2021-06-23 14:12:32 +02:00
|
|
|
user_notifications_data = UserMessageNotificationsData(
|
|
|
|
user_id=user_profile_id,
|
|
|
|
sender_is_muted=internal_data.get("sender_is_muted", False),
|
2023-08-04 22:08:17 +02:00
|
|
|
dm_push_notify=dm_push_notify,
|
|
|
|
dm_email_notify=dm_email_notify,
|
notifications: Calculate PMs/mentions settings like other settings.
Previously, we checked for the `enable_offline_email_notifications` and
`enable_offline_push_notifications` settings (which determine whether the
user will receive notifications for PMs and mentions) just before sending
notifications. This has a few problem:
1. We do not have access to all the user settings in the notification
handlers (`handle_missedmessage_emails` and `handle_push_notifications`),
and therefore, we cannot correctly determine whether the notification should
be sent. Checks like the following which existed previously, will, for
example, incorrectly not send notifications even when stream email
notifications are enabled-
```
if not receives_offline_email_notifications(user_profile):
return
```
With this commit, we simply do not enqueue notifications if the "offline"
settings are disabled, which fixes that bug.
Additionally, this also fixes a bug with the "online push notifications"
feature, which was, if someone were to:
* turn off notifications for PMs and mentions (`enable_offline_push_notifications`)
* turn on stream push notifications (`enable_stream_push_notifications`)
* turn on "online push" (`enable_online_push_notifications`)
then, they would still receive notifications for PMs when online.
This isn't how the "online push enabled" feature is supposed to work;
it should only act as a wrapper around the other notification settings.
The buggy code was this in `handle_push_notifications`:
```
if not (
receives_offline_push_notifications(user_profile)
or receives_online_push_notifications(user_profile)
):
return
// send notifications
```
This commit removes that code, and extends our `notification_data.py` logic
to cover this case, along with tests.
2. The name for these settings is slightly misleading. They essentially
talk about "what to send notifications for" (PMs and mentions), and not
"when to send notifications" (offline). This commit improves this condition
by restricting the use of this term only to the database field, and using
clearer names everywhere else. This distinction will be important to have
non-confusing code when we implement multiple options for notifications
in the future as dropdown (never/when offline/when offline or online, etc).
3. We should ideally re-check all notification settings just before the
notifications are sent. This is especially important for email notifications,
which may be sent after a long time after the message was sent. We will
in the future add code to thoroughly re-check settings before sending
notifications in a clean manner, but temporarily not re-checking isn't
a terrible scenario either.
2021-07-14 15:34:01 +02:00
|
|
|
mention_push_notify=internal_data.get("mention_push_notify", False),
|
|
|
|
mention_email_notify=internal_data.get("mention_email_notify", False),
|
2023-06-07 19:19:33 +02:00
|
|
|
topic_wildcard_mention_push_notify=internal_data.get(
|
|
|
|
"topic_wildcard_mention_push_notify", False
|
|
|
|
),
|
|
|
|
topic_wildcard_mention_email_notify=internal_data.get(
|
|
|
|
"topic_wildcard_mention_email_notify", False
|
|
|
|
),
|
2023-06-03 16:51:38 +02:00
|
|
|
stream_wildcard_mention_push_notify=stream_wildcard_mention_push_notify,
|
|
|
|
stream_wildcard_mention_email_notify=stream_wildcard_mention_email_notify,
|
maybe_enqueue_notifications: Take in notification_data dataclass.
* Modify `maybe_enqueue_notifications` to take in an instance of the
dataclass introduced in 951b49c048ba3464e74ad7965da3453fe36d0a96.
* The `check_notify` tests tested the "when to notify" logic in a way
which involved `maybe_enqueue_notifications`. To simplify things, we've
earlier extracted this logic in 8182632d7e9f8490b9b9295e01b5912dcf173fd5.
So, we just kill off the `check_notify` test, and keep only those parts
which verify the queueing and return value behavior of that funtion.
* We retain the the missedmessage_hook and message
message_edit_notifications since they are more integration-style.
* There's a slightly subtle change with the missedmessage_hook tests.
Before this commit, we short-circuited the hook if the sender was muted
(5a642cea115be159175d1189f83ba25d2c5c7632).
With this commit, we delegate the check to our dataclass methods.
So, `maybe_enqueue_notifications` will be called even if the sender was
muted, and the test needs to be updated.
* In our test helper `get_maybe_enqueue_notifications_parameters` which
generates default values for testing `maybe_enqueue_notifications` calls,
we keep `message_id`, `sender_id`, and `user_id` as required arguments,
so that the tests are super-clear and avoid accidental false positives.
* Because `do_update_embedded_data` also sends `update_message` events,
we deal with that case with some hacky code for now. See the comment
there.
This mostly completes the extraction of the "when to notify" logic into
our new `notification_data` module.
2021-06-23 14:12:32 +02:00
|
|
|
stream_push_notify=internal_data.get("stream_push_notify", False),
|
|
|
|
stream_email_notify=internal_data.get("stream_email_notify", False),
|
2023-05-28 17:03:04 +02:00
|
|
|
followed_topic_push_notify=internal_data.get("followed_topic_push_notify", False),
|
2023-05-17 16:01:16 +02:00
|
|
|
followed_topic_email_notify=internal_data.get("followed_topic_email_notify", False),
|
2023-06-07 19:19:33 +02:00
|
|
|
topic_wildcard_mention_in_followed_topic_push_notify=internal_data.get(
|
|
|
|
"topic_wildcard_mention_in_followed_topic_push_notify", False
|
|
|
|
),
|
|
|
|
topic_wildcard_mention_in_followed_topic_email_notify=internal_data.get(
|
|
|
|
"topic_wildcard_mention_in_followed_topic_email_notify", False
|
|
|
|
),
|
2023-06-03 16:51:38 +02:00
|
|
|
stream_wildcard_mention_in_followed_topic_push_notify=internal_data.get(
|
|
|
|
"stream_wildcard_mention_in_followed_topic_push_notify", False
|
2023-06-02 09:42:58 +02:00
|
|
|
),
|
2023-06-03 16:51:38 +02:00
|
|
|
stream_wildcard_mention_in_followed_topic_email_notify=internal_data.get(
|
|
|
|
"stream_wildcard_mention_in_followed_topic_email_notify", False
|
2023-06-02 09:42:58 +02:00
|
|
|
),
|
maybe_enqueue_notifications: Take in notification_data dataclass.
* Modify `maybe_enqueue_notifications` to take in an instance of the
dataclass introduced in 951b49c048ba3464e74ad7965da3453fe36d0a96.
* The `check_notify` tests tested the "when to notify" logic in a way
which involved `maybe_enqueue_notifications`. To simplify things, we've
earlier extracted this logic in 8182632d7e9f8490b9b9295e01b5912dcf173fd5.
So, we just kill off the `check_notify` test, and keep only those parts
which verify the queueing and return value behavior of that funtion.
* We retain the the missedmessage_hook and message
message_edit_notifications since they are more integration-style.
* There's a slightly subtle change with the missedmessage_hook tests.
Before this commit, we short-circuited the hook if the sender was muted
(5a642cea115be159175d1189f83ba25d2c5c7632).
With this commit, we delegate the check to our dataclass methods.
So, `maybe_enqueue_notifications` will be called even if the sender was
muted, and the test needs to be updated.
* In our test helper `get_maybe_enqueue_notifications_parameters` which
generates default values for testing `maybe_enqueue_notifications` calls,
we keep `message_id`, `sender_id`, and `user_id` as required arguments,
so that the tests are super-clear and avoid accidental false positives.
* Because `do_update_embedded_data` also sends `update_message` events,
we deal with that case with some hacky code for now. See the comment
there.
This mostly completes the extraction of the "when to notify" logic into
our new `notification_data` module.
2021-06-23 14:12:32 +02:00
|
|
|
# Since one is by definition idle, we don't need to check online_push_enabled
|
|
|
|
online_push_enabled=False,
|
2022-10-22 13:25:06 +02:00
|
|
|
disable_external_notifications=internal_data.get(
|
|
|
|
"disable_external_notifications", False
|
|
|
|
),
|
maybe_enqueue_notifications: Take in notification_data dataclass.
* Modify `maybe_enqueue_notifications` to take in an instance of the
dataclass introduced in 951b49c048ba3464e74ad7965da3453fe36d0a96.
* The `check_notify` tests tested the "when to notify" logic in a way
which involved `maybe_enqueue_notifications`. To simplify things, we've
earlier extracted this logic in 8182632d7e9f8490b9b9295e01b5912dcf173fd5.
So, we just kill off the `check_notify` test, and keep only those parts
which verify the queueing and return value behavior of that funtion.
* We retain the the missedmessage_hook and message
message_edit_notifications since they are more integration-style.
* There's a slightly subtle change with the missedmessage_hook tests.
Before this commit, we short-circuited the hook if the sender was muted
(5a642cea115be159175d1189f83ba25d2c5c7632).
With this commit, we delegate the check to our dataclass methods.
So, `maybe_enqueue_notifications` will be called even if the sender was
muted, and the test needs to be updated.
* In our test helper `get_maybe_enqueue_notifications_parameters` which
generates default values for testing `maybe_enqueue_notifications` calls,
we keep `message_id`, `sender_id`, and `user_id` as required arguments,
so that the tests are super-clear and avoid accidental false positives.
* Because `do_update_embedded_data` also sends `update_message` events,
we deal with that case with some hacky code for now. See the comment
there.
This mostly completes the extraction of the "when to notify" logic into
our new `notification_data` module.
2021-06-23 14:12:32 +02:00
|
|
|
)
|
2014-04-24 02:16:53 +02:00
|
|
|
|
2021-07-01 17:40:16 +02:00
|
|
|
mentioned_user_group_id = internal_data.get("mentioned_user_group_id")
|
2017-09-28 00:04:32 +02:00
|
|
|
|
2017-09-21 14:04:58 +02:00
|
|
|
# Since we just GC'd the last event queue, the user is definitely idle.
|
|
|
|
idle = True
|
|
|
|
|
2021-02-12 08:20:45 +01:00
|
|
|
message_id = event["message"]["id"]
|
2017-10-18 06:54:03 +02:00
|
|
|
# Pass on the information on whether a push or email notification was already sent.
|
|
|
|
already_notified = dict(
|
2021-06-11 14:27:00 +02:00
|
|
|
push_notified=internal_data.get("push_notified", False),
|
|
|
|
email_notified=internal_data.get("email_notified", False),
|
2017-10-18 06:54:03 +02:00
|
|
|
)
|
2021-02-12 08:19:30 +01:00
|
|
|
maybe_enqueue_notifications(
|
2021-06-25 14:08:41 +02:00
|
|
|
user_notifications_data=user_notifications_data,
|
2021-06-25 13:58:53 +02:00
|
|
|
acting_user_id=sender_id,
|
2021-06-23 12:25:38 +02:00
|
|
|
message_id=message_id,
|
2021-07-01 17:40:16 +02:00
|
|
|
mentioned_user_group_id=mentioned_user_group_id,
|
2021-06-23 12:25:38 +02:00
|
|
|
idle=idle,
|
|
|
|
already_notified=already_notified,
|
2021-02-12 08:19:30 +01:00
|
|
|
)
|
|
|
|
|
2014-04-24 02:16:53 +02:00
|
|
|
|
2017-11-27 11:09:23 +01:00
|
|
|
def receiver_is_off_zulip(user_profile_id: int) -> bool:
|
2014-04-24 02:16:53 +02:00
|
|
|
# If a user has no message-receiving event queues, they've got no open zulip
|
2020-12-19 03:05:20 +01:00
|
|
|
# session so we notify them.
|
2014-04-24 02:16:53 +02:00
|
|
|
all_client_descriptors = get_client_descriptors_for_user(user_profile_id)
|
2021-02-12 08:19:30 +01:00
|
|
|
message_event_queues = [
|
|
|
|
client for client in all_client_descriptors if client.accepts_messages()
|
|
|
|
]
|
2014-04-24 02:16:53 +02:00
|
|
|
off_zulip = len(message_event_queues) == 0
|
2017-09-05 20:13:05 +02:00
|
|
|
return off_zulip
|
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
|
|
|
def maybe_enqueue_notifications(
|
2021-06-23 12:25:38 +02:00
|
|
|
*,
|
2021-06-25 14:08:41 +02:00
|
|
|
user_notifications_data: UserMessageNotificationsData,
|
2021-06-25 13:58:53 +02:00
|
|
|
acting_user_id: int,
|
2021-02-12 08:19:30 +01:00
|
|
|
message_id: int,
|
2024-07-12 02:30:23 +02:00
|
|
|
mentioned_user_group_id: int | None,
|
2021-02-12 08:19:30 +01:00
|
|
|
idle: bool,
|
2024-07-12 02:30:17 +02:00
|
|
|
already_notified: dict[str, bool],
|
|
|
|
) -> dict[str, bool]:
|
2017-09-27 20:27:04 +02:00
|
|
|
"""This function has a complete unit test suite in
|
|
|
|
`test_enqueue_notifications` that should be expanded as we add
|
2020-12-19 03:05:20 +01:00
|
|
|
more features here.
|
|
|
|
|
|
|
|
See https://zulip.readthedocs.io/en/latest/subsystems/notifications.html
|
|
|
|
for high-level design documentation.
|
|
|
|
"""
|
2024-07-12 02:30:17 +02:00
|
|
|
notified: dict[str, bool] = {}
|
2017-09-21 13:52:46 +02:00
|
|
|
|
notifications: Calculate PMs/mentions settings like other settings.
Previously, we checked for the `enable_offline_email_notifications` and
`enable_offline_push_notifications` settings (which determine whether the
user will receive notifications for PMs and mentions) just before sending
notifications. This has a few problem:
1. We do not have access to all the user settings in the notification
handlers (`handle_missedmessage_emails` and `handle_push_notifications`),
and therefore, we cannot correctly determine whether the notification should
be sent. Checks like the following which existed previously, will, for
example, incorrectly not send notifications even when stream email
notifications are enabled-
```
if not receives_offline_email_notifications(user_profile):
return
```
With this commit, we simply do not enqueue notifications if the "offline"
settings are disabled, which fixes that bug.
Additionally, this also fixes a bug with the "online push notifications"
feature, which was, if someone were to:
* turn off notifications for PMs and mentions (`enable_offline_push_notifications`)
* turn on stream push notifications (`enable_stream_push_notifications`)
* turn on "online push" (`enable_online_push_notifications`)
then, they would still receive notifications for PMs when online.
This isn't how the "online push enabled" feature is supposed to work;
it should only act as a wrapper around the other notification settings.
The buggy code was this in `handle_push_notifications`:
```
if not (
receives_offline_push_notifications(user_profile)
or receives_online_push_notifications(user_profile)
):
return
// send notifications
```
This commit removes that code, and extends our `notification_data.py` logic
to cover this case, along with tests.
2. The name for these settings is slightly misleading. They essentially
talk about "what to send notifications for" (PMs and mentions), and not
"when to send notifications" (offline). This commit improves this condition
by restricting the use of this term only to the database field, and using
clearer names everywhere else. This distinction will be important to have
non-confusing code when we implement multiple options for notifications
in the future as dropdown (never/when offline/when offline or online, etc).
3. We should ideally re-check all notification settings just before the
notifications are sent. This is especially important for email notifications,
which may be sent after a long time after the message was sent. We will
in the future add code to thoroughly re-check settings before sending
notifications in a clean manner, but temporarily not re-checking isn't
a terrible scenario either.
2021-07-14 15:34:01 +02:00
|
|
|
if user_notifications_data.is_push_notifiable(acting_user_id, idle):
|
2021-06-25 14:08:41 +02:00
|
|
|
notice = build_offline_notification(user_notifications_data.user_id, message_id)
|
|
|
|
notice["trigger"] = user_notifications_data.get_push_notification_trigger(
|
notifications: Calculate PMs/mentions settings like other settings.
Previously, we checked for the `enable_offline_email_notifications` and
`enable_offline_push_notifications` settings (which determine whether the
user will receive notifications for PMs and mentions) just before sending
notifications. This has a few problem:
1. We do not have access to all the user settings in the notification
handlers (`handle_missedmessage_emails` and `handle_push_notifications`),
and therefore, we cannot correctly determine whether the notification should
be sent. Checks like the following which existed previously, will, for
example, incorrectly not send notifications even when stream email
notifications are enabled-
```
if not receives_offline_email_notifications(user_profile):
return
```
With this commit, we simply do not enqueue notifications if the "offline"
settings are disabled, which fixes that bug.
Additionally, this also fixes a bug with the "online push notifications"
feature, which was, if someone were to:
* turn off notifications for PMs and mentions (`enable_offline_push_notifications`)
* turn on stream push notifications (`enable_stream_push_notifications`)
* turn on "online push" (`enable_online_push_notifications`)
then, they would still receive notifications for PMs when online.
This isn't how the "online push enabled" feature is supposed to work;
it should only act as a wrapper around the other notification settings.
The buggy code was this in `handle_push_notifications`:
```
if not (
receives_offline_push_notifications(user_profile)
or receives_online_push_notifications(user_profile)
):
return
// send notifications
```
This commit removes that code, and extends our `notification_data.py` logic
to cover this case, along with tests.
2. The name for these settings is slightly misleading. They essentially
talk about "what to send notifications for" (PMs and mentions), and not
"when to send notifications" (offline). This commit improves this condition
by restricting the use of this term only to the database field, and using
clearer names everywhere else. This distinction will be important to have
non-confusing code when we implement multiple options for notifications
in the future as dropdown (never/when offline/when offline or online, etc).
3. We should ideally re-check all notification settings just before the
notifications are sent. This is especially important for email notifications,
which may be sent after a long time after the message was sent. We will
in the future add code to thoroughly re-check settings before sending
notifications in a clean manner, but temporarily not re-checking isn't
a terrible scenario either.
2021-07-14 15:34:01 +02:00
|
|
|
acting_user_id, idle
|
2021-06-24 15:44:42 +02:00
|
|
|
)
|
2021-07-08 07:30:40 +02:00
|
|
|
notice["type"] = "add"
|
2021-07-01 17:40:16 +02:00
|
|
|
notice["mentioned_user_group_id"] = mentioned_user_group_id
|
2017-10-18 06:54:03 +02:00
|
|
|
if not already_notified.get("push_notified"):
|
2023-12-04 18:35:04 +01:00
|
|
|
if settings.MOBILE_NOTIFICATIONS_SHARDS > 1:
|
|
|
|
shard_id = (
|
|
|
|
user_notifications_data.user_id % settings.MOBILE_NOTIFICATIONS_SHARDS + 1
|
|
|
|
)
|
|
|
|
queue_json_publish(f"missedmessage_mobile_notifications_shard{shard_id}", notice)
|
|
|
|
else:
|
|
|
|
queue_json_publish("missedmessage_mobile_notifications", notice)
|
2021-02-12 08:20:45 +01:00
|
|
|
notified["push_notified"] = True
|
2017-09-21 13:52:46 +02:00
|
|
|
|
2023-06-19 16:42:11 +02:00
|
|
|
# Send missed_message emails if a direct message or a
|
2017-09-21 13:52:46 +02:00
|
|
|
# mention. Eventually, we'll add settings to allow email
|
|
|
|
# notifications to match the model of push notifications
|
|
|
|
# above.
|
notifications: Calculate PMs/mentions settings like other settings.
Previously, we checked for the `enable_offline_email_notifications` and
`enable_offline_push_notifications` settings (which determine whether the
user will receive notifications for PMs and mentions) just before sending
notifications. This has a few problem:
1. We do not have access to all the user settings in the notification
handlers (`handle_missedmessage_emails` and `handle_push_notifications`),
and therefore, we cannot correctly determine whether the notification should
be sent. Checks like the following which existed previously, will, for
example, incorrectly not send notifications even when stream email
notifications are enabled-
```
if not receives_offline_email_notifications(user_profile):
return
```
With this commit, we simply do not enqueue notifications if the "offline"
settings are disabled, which fixes that bug.
Additionally, this also fixes a bug with the "online push notifications"
feature, which was, if someone were to:
* turn off notifications for PMs and mentions (`enable_offline_push_notifications`)
* turn on stream push notifications (`enable_stream_push_notifications`)
* turn on "online push" (`enable_online_push_notifications`)
then, they would still receive notifications for PMs when online.
This isn't how the "online push enabled" feature is supposed to work;
it should only act as a wrapper around the other notification settings.
The buggy code was this in `handle_push_notifications`:
```
if not (
receives_offline_push_notifications(user_profile)
or receives_online_push_notifications(user_profile)
):
return
// send notifications
```
This commit removes that code, and extends our `notification_data.py` logic
to cover this case, along with tests.
2. The name for these settings is slightly misleading. They essentially
talk about "what to send notifications for" (PMs and mentions), and not
"when to send notifications" (offline). This commit improves this condition
by restricting the use of this term only to the database field, and using
clearer names everywhere else. This distinction will be important to have
non-confusing code when we implement multiple options for notifications
in the future as dropdown (never/when offline/when offline or online, etc).
3. We should ideally re-check all notification settings just before the
notifications are sent. This is especially important for email notifications,
which may be sent after a long time after the message was sent. We will
in the future add code to thoroughly re-check settings before sending
notifications in a clean manner, but temporarily not re-checking isn't
a terrible scenario either.
2021-07-14 15:34:01 +02:00
|
|
|
if user_notifications_data.is_email_notifiable(acting_user_id, idle):
|
2021-06-25 14:08:41 +02:00
|
|
|
notice = build_offline_notification(user_notifications_data.user_id, message_id)
|
|
|
|
notice["trigger"] = user_notifications_data.get_email_notification_trigger(
|
notifications: Calculate PMs/mentions settings like other settings.
Previously, we checked for the `enable_offline_email_notifications` and
`enable_offline_push_notifications` settings (which determine whether the
user will receive notifications for PMs and mentions) just before sending
notifications. This has a few problem:
1. We do not have access to all the user settings in the notification
handlers (`handle_missedmessage_emails` and `handle_push_notifications`),
and therefore, we cannot correctly determine whether the notification should
be sent. Checks like the following which existed previously, will, for
example, incorrectly not send notifications even when stream email
notifications are enabled-
```
if not receives_offline_email_notifications(user_profile):
return
```
With this commit, we simply do not enqueue notifications if the "offline"
settings are disabled, which fixes that bug.
Additionally, this also fixes a bug with the "online push notifications"
feature, which was, if someone were to:
* turn off notifications for PMs and mentions (`enable_offline_push_notifications`)
* turn on stream push notifications (`enable_stream_push_notifications`)
* turn on "online push" (`enable_online_push_notifications`)
then, they would still receive notifications for PMs when online.
This isn't how the "online push enabled" feature is supposed to work;
it should only act as a wrapper around the other notification settings.
The buggy code was this in `handle_push_notifications`:
```
if not (
receives_offline_push_notifications(user_profile)
or receives_online_push_notifications(user_profile)
):
return
// send notifications
```
This commit removes that code, and extends our `notification_data.py` logic
to cover this case, along with tests.
2. The name for these settings is slightly misleading. They essentially
talk about "what to send notifications for" (PMs and mentions), and not
"when to send notifications" (offline). This commit improves this condition
by restricting the use of this term only to the database field, and using
clearer names everywhere else. This distinction will be important to have
non-confusing code when we implement multiple options for notifications
in the future as dropdown (never/when offline/when offline or online, etc).
3. We should ideally re-check all notification settings just before the
notifications are sent. This is especially important for email notifications,
which may be sent after a long time after the message was sent. We will
in the future add code to thoroughly re-check settings before sending
notifications in a clean manner, but temporarily not re-checking isn't
a terrible scenario either.
2021-07-14 15:34:01 +02:00
|
|
|
acting_user_id, idle
|
2021-06-24 15:44:42 +02:00
|
|
|
)
|
2021-07-01 17:40:16 +02:00
|
|
|
notice["mentioned_user_group_id"] = mentioned_user_group_id
|
2017-10-18 06:54:03 +02:00
|
|
|
if not already_notified.get("email_notified"):
|
|
|
|
queue_json_publish("missedmessage_emails", notice, lambda notice: None)
|
2021-02-12 08:20:45 +01:00
|
|
|
notified["email_notified"] = True
|
2017-09-21 13:52:46 +02:00
|
|
|
|
2017-09-28 00:10:18 +02:00
|
|
|
return notified
|
2017-09-21 13:52:46 +02:00
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
2020-05-02 06:24:43 +02:00
|
|
|
class ClientInfo(TypedDict):
|
|
|
|
client: ClientDescriptor
|
2021-04-30 00:15:33 +02:00
|
|
|
flags: Collection[str]
|
2020-05-02 06:24:43 +02:00
|
|
|
is_sender: bool
|
2017-10-26 22:10:52 +02:00
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
|
|
|
def get_client_info_for_message_event(
|
|
|
|
event_template: Mapping[str, Any], users: Iterable[Mapping[str, Any]]
|
2024-07-12 02:30:17 +02:00
|
|
|
) -> dict[str, ClientInfo]:
|
2021-02-12 08:19:30 +01:00
|
|
|
"""
|
2017-10-26 22:10:52 +02:00
|
|
|
Return client info for all the clients interested in a message.
|
|
|
|
This basically includes clients for users who are recipients
|
|
|
|
of the message, with some nuances for bots that auto-subscribe
|
|
|
|
to all streams, plus users who may be mentioned, etc.
|
2021-02-12 08:19:30 +01:00
|
|
|
"""
|
2017-10-26 22:10:52 +02:00
|
|
|
|
2024-07-12 02:30:17 +02:00
|
|
|
send_to_clients: dict[str, ClientInfo] = {}
|
2017-10-26 22:10:52 +02:00
|
|
|
|
2024-07-12 02:30:23 +02:00
|
|
|
sender_queue_id: str | None = event_template.get("sender_queue_id", None)
|
2017-10-26 22:10:52 +02:00
|
|
|
|
2017-11-27 11:09:23 +01:00
|
|
|
def is_sender_client(client: ClientDescriptor) -> bool:
|
2017-10-26 22:10:52 +02:00
|
|
|
return (sender_queue_id is not None) and client.event_queue.id == sender_queue_id
|
|
|
|
|
|
|
|
# If we're on a public stream, look for clients (typically belonging to
|
|
|
|
# bots) that are registered to get events for ALL streams.
|
2021-02-12 08:20:45 +01:00
|
|
|
if "stream_name" in event_template and not event_template.get("invite_only"):
|
|
|
|
realm_id = event_template["realm_id"]
|
2017-10-26 22:10:52 +02:00
|
|
|
for client in get_client_descriptors_for_realm_all_streams(realm_id):
|
|
|
|
send_to_clients[client.event_queue.id] = dict(
|
|
|
|
client=client,
|
2018-03-28 21:42:06 +02:00
|
|
|
flags=[],
|
python: Use trailing commas consistently.
Automatically generated by the following script, based on the output
of lint with flake8-comma:
import re
import sys
last_filename = None
last_row = None
lines = []
for msg in sys.stdin:
m = re.match(
r"\x1b\[35mflake8 \|\x1b\[0m \x1b\[1;31m(.+):(\d+):(\d+): (\w+)", msg
)
if m:
filename, row_str, col_str, err = m.groups()
row, col = int(row_str), int(col_str)
if filename == last_filename:
assert last_row != row
else:
if last_filename is not None:
with open(last_filename, "w") as f:
f.writelines(lines)
with open(filename) as f:
lines = f.readlines()
last_filename = filename
last_row = row
line = lines[row - 1]
if err in ["C812", "C815"]:
lines[row - 1] = line[: col - 1] + "," + line[col - 1 :]
elif err in ["C819"]:
assert line[col - 2] == ","
lines[row - 1] = line[: col - 2] + line[col - 1 :].lstrip(" ")
if last_filename is not None:
with open(last_filename, "w") as f:
f.writelines(lines)
Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
2020-04-10 05:23:40 +02:00
|
|
|
is_sender=is_sender_client(client),
|
2017-10-26 22:10:52 +02:00
|
|
|
)
|
|
|
|
|
|
|
|
for user_data in users:
|
2021-02-12 08:20:45 +01:00
|
|
|
user_profile_id: int = user_data["id"]
|
2021-04-30 00:15:33 +02:00
|
|
|
flags: Collection[str] = user_data.get("flags", [])
|
2017-10-26 22:10:52 +02:00
|
|
|
|
|
|
|
for client in get_client_descriptors_for_user(user_profile_id):
|
|
|
|
send_to_clients[client.event_queue.id] = dict(
|
|
|
|
client=client,
|
|
|
|
flags=flags,
|
python: Use trailing commas consistently.
Automatically generated by the following script, based on the output
of lint with flake8-comma:
import re
import sys
last_filename = None
last_row = None
lines = []
for msg in sys.stdin:
m = re.match(
r"\x1b\[35mflake8 \|\x1b\[0m \x1b\[1;31m(.+):(\d+):(\d+): (\w+)", msg
)
if m:
filename, row_str, col_str, err = m.groups()
row, col = int(row_str), int(col_str)
if filename == last_filename:
assert last_row != row
else:
if last_filename is not None:
with open(last_filename, "w") as f:
f.writelines(lines)
with open(filename) as f:
lines = f.readlines()
last_filename = filename
last_row = row
line = lines[row - 1]
if err in ["C812", "C815"]:
lines[row - 1] = line[: col - 1] + "," + line[col - 1 :]
elif err in ["C819"]:
assert line[col - 2] == ","
lines[row - 1] = line[: col - 2] + line[col - 1 :].lstrip(" ")
if last_filename is not None:
with open(last_filename, "w") as f:
f.writelines(lines)
Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
2020-04-10 05:23:40 +02:00
|
|
|
is_sender=is_sender_client(client),
|
2017-10-26 22:10:52 +02:00
|
|
|
)
|
|
|
|
|
|
|
|
return send_to_clients
|
|
|
|
|
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
def process_message_event(
|
2021-04-30 00:15:33 +02:00
|
|
|
event_template: Mapping[str, Any], users: Collection[Mapping[str, Any]]
|
2021-02-12 08:19:30 +01:00
|
|
|
) -> None:
|
2018-11-30 00:48:13 +01:00
|
|
|
"""See
|
|
|
|
https://zulip.readthedocs.io/en/latest/subsystems/sending-messages.html
|
|
|
|
for high-level documentation on this subsystem.
|
|
|
|
"""
|
2017-10-26 22:10:52 +02:00
|
|
|
send_to_clients = get_client_info_for_message_event(event_template, users)
|
|
|
|
|
2021-02-12 08:20:45 +01:00
|
|
|
presence_idle_user_ids = set(event_template.get("presence_idle_user_ids", []))
|
2021-06-18 19:30:57 +02:00
|
|
|
online_push_user_ids = set(event_template.get("online_push_user_ids", []))
|
2023-08-04 22:08:17 +02:00
|
|
|
|
|
|
|
# TODO/compatibility: Translation code for the rename of
|
|
|
|
# `pm_mention_push_disabled_user_ids` to `dm_mention_push_disabled_user_ids`.
|
|
|
|
# Remove this when one can no longer directly upgrade from 7.x to main.
|
|
|
|
dm_mention_push_disabled_user_ids = set()
|
|
|
|
if "dm_mention_push_disabled_user_ids" in event_template:
|
|
|
|
dm_mention_push_disabled_user_ids = set(
|
|
|
|
event_template.get("dm_mention_push_disabled_user_ids", [])
|
|
|
|
)
|
|
|
|
elif "pm_mention_push_disabled_user_ids" in event_template:
|
|
|
|
dm_mention_push_disabled_user_ids = set(
|
|
|
|
event_template.get("pm_mention_push_disabled_user_ids", [])
|
|
|
|
)
|
|
|
|
|
|
|
|
# TODO/compatibility: Translation code for the rename of
|
|
|
|
# `pm_mention_email_disabled_user_ids` to `dm_mention_email_disabled_user_ids`.
|
|
|
|
# Remove this when one can no longer directly upgrade from 7.x to main.
|
|
|
|
dm_mention_email_disabled_user_ids = set()
|
|
|
|
if "dm_mention_email_disabled_user_ids" in event_template:
|
|
|
|
dm_mention_email_disabled_user_ids = set(
|
|
|
|
event_template.get("dm_mention_email_disabled_user_ids", [])
|
|
|
|
)
|
|
|
|
elif "pm_mention_email_disabled_user_ids" in event_template:
|
|
|
|
dm_mention_email_disabled_user_ids = set(
|
|
|
|
event_template.get("pm_mention_email_disabled_user_ids", [])
|
|
|
|
)
|
|
|
|
|
2021-06-18 19:30:57 +02:00
|
|
|
stream_push_user_ids = set(event_template.get("stream_push_user_ids", []))
|
|
|
|
stream_email_user_ids = set(event_template.get("stream_email_user_ids", []))
|
2023-06-07 19:19:33 +02:00
|
|
|
topic_wildcard_mention_user_ids = set(event_template.get("topic_wildcard_mention_user_ids", []))
|
2023-06-03 16:51:38 +02:00
|
|
|
|
|
|
|
# TODO/compatibility: Translation code for the rename of
|
|
|
|
# `wildcard_mention_user_ids` to `stream_wildcard_mention_user_ids`.
|
|
|
|
# Remove this when one can no longer directly upgrade from 7.x to main.
|
|
|
|
stream_wildcard_mention_user_ids = set()
|
|
|
|
if "stream_wildcard_mention_user_ids" in event_template:
|
|
|
|
stream_wildcard_mention_user_ids = set(
|
|
|
|
event_template.get("stream_wildcard_mention_user_ids", [])
|
|
|
|
)
|
|
|
|
elif "wildcard_mention_user_ids" in event_template:
|
|
|
|
stream_wildcard_mention_user_ids = set(event_template.get("wildcard_mention_user_ids", []))
|
|
|
|
|
2023-05-28 17:03:04 +02:00
|
|
|
followed_topic_push_user_ids = set(event_template.get("followed_topic_push_user_ids", []))
|
2023-05-17 16:01:16 +02:00
|
|
|
followed_topic_email_user_ids = set(event_template.get("followed_topic_email_user_ids", []))
|
2023-06-07 19:19:33 +02:00
|
|
|
topic_wildcard_mention_in_followed_topic_user_ids = set(
|
|
|
|
event_template.get("topic_wildcard_mention_in_followed_topic_user_ids", [])
|
|
|
|
)
|
2023-06-03 16:51:38 +02:00
|
|
|
stream_wildcard_mention_in_followed_topic_user_ids = set(
|
|
|
|
event_template.get("stream_wildcard_mention_in_followed_topic_user_ids", [])
|
2023-06-02 09:42:58 +02:00
|
|
|
)
|
2021-06-18 19:30:57 +02:00
|
|
|
muted_sender_user_ids = set(event_template.get("muted_sender_user_ids", []))
|
2021-12-19 12:04:36 +01:00
|
|
|
all_bot_user_ids = set(event_template.get("all_bot_user_ids", []))
|
2022-10-22 13:25:06 +02:00
|
|
|
disable_external_notifications = event_template.get("disable_external_notifications", False)
|
2023-11-08 04:53:05 +01:00
|
|
|
user_ids_without_access_to_sender = event_template.get("user_ids_without_access_to_sender", [])
|
|
|
|
realm_host = event_template.get("realm_host", "")
|
2021-06-18 19:30:57 +02:00
|
|
|
|
2024-07-12 02:30:17 +02:00
|
|
|
wide_dict: dict[str, Any] = event_template["message_dict"]
|
2017-10-20 21:34:05 +02:00
|
|
|
|
2020-03-28 11:41:45 +01:00
|
|
|
# Temporary transitional code: Zulip servers that have message
|
|
|
|
# events in their event queues and upgrade to the new version
|
|
|
|
# that expects sender_delivery_email in these events will
|
|
|
|
# throw errors processing events. We can remove this block
|
|
|
|
# once we don't expect anyone to be directly upgrading from
|
|
|
|
# 2.0.x to the latest Zulip.
|
2021-02-12 08:20:45 +01:00
|
|
|
if "sender_delivery_email" not in wide_dict: # nocoverage
|
|
|
|
wide_dict["sender_delivery_email"] = wide_dict["sender_email"]
|
2020-03-28 11:41:45 +01:00
|
|
|
|
2021-02-12 08:20:45 +01:00
|
|
|
sender_id: int = wide_dict["sender_id"]
|
|
|
|
message_id: int = wide_dict["id"]
|
2023-04-18 17:23:58 +02:00
|
|
|
recipient_type_name: str = wide_dict["type"]
|
2021-02-12 08:20:45 +01:00
|
|
|
sending_client: str = wide_dict["client"]
|
2017-10-20 21:34:05 +02:00
|
|
|
|
2024-04-02 00:19:08 +02:00
|
|
|
@cache
|
2023-11-08 04:53:05 +01:00
|
|
|
def get_client_payload(
|
|
|
|
apply_markdown: bool, client_gravatar: bool, can_access_sender: bool
|
2024-07-12 02:30:17 +02:00
|
|
|
) -> dict[str, Any]:
|
2020-03-26 23:16:23 +01:00
|
|
|
return MessageDict.finalize_payload(
|
|
|
|
wide_dict,
|
|
|
|
apply_markdown=apply_markdown,
|
python: Use trailing commas consistently.
Automatically generated by the following script, based on the output
of lint with flake8-comma:
import re
import sys
last_filename = None
last_row = None
lines = []
for msg in sys.stdin:
m = re.match(
r"\x1b\[35mflake8 \|\x1b\[0m \x1b\[1;31m(.+):(\d+):(\d+): (\w+)", msg
)
if m:
filename, row_str, col_str, err = m.groups()
row, col = int(row_str), int(col_str)
if filename == last_filename:
assert last_row != row
else:
if last_filename is not None:
with open(last_filename, "w") as f:
f.writelines(lines)
with open(filename) as f:
lines = f.readlines()
last_filename = filename
last_row = row
line = lines[row - 1]
if err in ["C812", "C815"]:
lines[row - 1] = line[: col - 1] + "," + line[col - 1 :]
elif err in ["C819"]:
assert line[col - 2] == ","
lines[row - 1] = line[: col - 2] + line[col - 1 :].lstrip(" ")
if last_filename is not None:
with open(last_filename, "w") as f:
f.writelines(lines)
Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
2020-04-10 05:23:40 +02:00
|
|
|
client_gravatar=client_gravatar,
|
2023-11-08 04:53:05 +01:00
|
|
|
can_access_sender=can_access_sender,
|
|
|
|
realm_host=realm_host,
|
2020-03-26 23:16:23 +01:00
|
|
|
)
|
2014-04-24 02:16:53 +02:00
|
|
|
|
|
|
|
# Extra user-specific data to include
|
2024-07-12 02:30:17 +02:00
|
|
|
extra_user_data: dict[int, Any] = {}
|
2014-04-24 02:16:53 +02:00
|
|
|
|
|
|
|
for user_data in users:
|
2021-02-12 08:20:45 +01:00
|
|
|
user_profile_id: int = user_data["id"]
|
2021-06-21 15:25:47 +02:00
|
|
|
flags: Collection[str] = user_data.get("flags", [])
|
2024-07-12 02:30:23 +02:00
|
|
|
mentioned_user_group_id: int | None = user_data.get("mentioned_user_group_id")
|
2014-04-24 02:16:53 +02:00
|
|
|
|
2023-06-19 16:42:11 +02:00
|
|
|
# If the recipient was offline and the message was a (1:1 or group) direct message
|
|
|
|
# to them or they were @-notified potentially notify more immediately
|
2023-04-18 17:23:58 +02:00
|
|
|
private_message = recipient_type_name == "private"
|
2021-06-21 16:48:13 +02:00
|
|
|
user_notifications_data = UserMessageNotificationsData.from_user_id_sets(
|
|
|
|
user_id=user_profile_id,
|
|
|
|
flags=flags,
|
notifications: Calculate PMs/mentions settings like other settings.
Previously, we checked for the `enable_offline_email_notifications` and
`enable_offline_push_notifications` settings (which determine whether the
user will receive notifications for PMs and mentions) just before sending
notifications. This has a few problem:
1. We do not have access to all the user settings in the notification
handlers (`handle_missedmessage_emails` and `handle_push_notifications`),
and therefore, we cannot correctly determine whether the notification should
be sent. Checks like the following which existed previously, will, for
example, incorrectly not send notifications even when stream email
notifications are enabled-
```
if not receives_offline_email_notifications(user_profile):
return
```
With this commit, we simply do not enqueue notifications if the "offline"
settings are disabled, which fixes that bug.
Additionally, this also fixes a bug with the "online push notifications"
feature, which was, if someone were to:
* turn off notifications for PMs and mentions (`enable_offline_push_notifications`)
* turn on stream push notifications (`enable_stream_push_notifications`)
* turn on "online push" (`enable_online_push_notifications`)
then, they would still receive notifications for PMs when online.
This isn't how the "online push enabled" feature is supposed to work;
it should only act as a wrapper around the other notification settings.
The buggy code was this in `handle_push_notifications`:
```
if not (
receives_offline_push_notifications(user_profile)
or receives_online_push_notifications(user_profile)
):
return
// send notifications
```
This commit removes that code, and extends our `notification_data.py` logic
to cover this case, along with tests.
2. The name for these settings is slightly misleading. They essentially
talk about "what to send notifications for" (PMs and mentions), and not
"when to send notifications" (offline). This commit improves this condition
by restricting the use of this term only to the database field, and using
clearer names everywhere else. This distinction will be important to have
non-confusing code when we implement multiple options for notifications
in the future as dropdown (never/when offline/when offline or online, etc).
3. We should ideally re-check all notification settings just before the
notifications are sent. This is especially important for email notifications,
which may be sent after a long time after the message was sent. We will
in the future add code to thoroughly re-check settings before sending
notifications in a clean manner, but temporarily not re-checking isn't
a terrible scenario either.
2021-07-14 15:34:01 +02:00
|
|
|
private_message=private_message,
|
2022-10-22 13:25:06 +02:00
|
|
|
disable_external_notifications=disable_external_notifications,
|
2021-06-21 16:48:13 +02:00
|
|
|
online_push_user_ids=online_push_user_ids,
|
2023-08-04 22:08:17 +02:00
|
|
|
dm_mention_push_disabled_user_ids=dm_mention_push_disabled_user_ids,
|
|
|
|
dm_mention_email_disabled_user_ids=dm_mention_email_disabled_user_ids,
|
2021-06-21 16:48:13 +02:00
|
|
|
stream_push_user_ids=stream_push_user_ids,
|
|
|
|
stream_email_user_ids=stream_email_user_ids,
|
2023-06-07 19:19:33 +02:00
|
|
|
topic_wildcard_mention_user_ids=topic_wildcard_mention_user_ids,
|
2023-06-03 16:51:38 +02:00
|
|
|
stream_wildcard_mention_user_ids=stream_wildcard_mention_user_ids,
|
2023-05-28 17:03:04 +02:00
|
|
|
followed_topic_push_user_ids=followed_topic_push_user_ids,
|
2023-05-17 16:01:16 +02:00
|
|
|
followed_topic_email_user_ids=followed_topic_email_user_ids,
|
2023-06-07 19:19:33 +02:00
|
|
|
topic_wildcard_mention_in_followed_topic_user_ids=topic_wildcard_mention_in_followed_topic_user_ids,
|
2023-06-03 16:51:38 +02:00
|
|
|
stream_wildcard_mention_in_followed_topic_user_ids=stream_wildcard_mention_in_followed_topic_user_ids,
|
2021-06-21 16:48:13 +02:00
|
|
|
muted_sender_user_ids=muted_sender_user_ids,
|
2021-12-19 12:04:36 +01:00
|
|
|
all_bot_user_ids=all_bot_user_ids,
|
2021-06-14 14:00:01 +02:00
|
|
|
)
|
|
|
|
|
tornado: Replace dataclasses.asdict() call, as it is slow.
This code is called in the hot path when Tornado is processing events.
As such, making this code performant is important. Profiling shows
that a significant portion of the time is spent calling asdict() to
serialize the UserMessageNotificationsData dataclass. In this case
`asdict` does several steps which we do not need, such as attempting
to recurse into its fields, and deepcopy'ing the values of the fields.
In our use case, these add a notable amount of overhead:
```py3
from zerver.tornado.event_queue import UserMessageNotificationsData
from dataclasses import asdict
from timeit import timeit
o = UserMessageNotificationsData(1, False, False, False, False, False, False, False, False, False, False, False)
%timeit asdict(o)
%timeit {**vars(o)}
```
Replace the `asdict` call with a direct access of the fields. We
perform a shallow copy because we do need to modify the resulting
fields.
2023-02-17 20:27:57 +01:00
|
|
|
# Calling asdict would be slow, as it does a deep copy; pull
|
|
|
|
# the attributes out directly and perform a shallow copy, as
|
|
|
|
# we do intend to adjust the dict.
|
|
|
|
internal_data = {**vars(user_notifications_data)}
|
|
|
|
|
maybe_enqueue_notifications: Take in notification_data dataclass.
* Modify `maybe_enqueue_notifications` to take in an instance of the
dataclass introduced in 951b49c048ba3464e74ad7965da3453fe36d0a96.
* The `check_notify` tests tested the "when to notify" logic in a way
which involved `maybe_enqueue_notifications`. To simplify things, we've
earlier extracted this logic in 8182632d7e9f8490b9b9295e01b5912dcf173fd5.
So, we just kill off the `check_notify` test, and keep only those parts
which verify the queueing and return value behavior of that funtion.
* We retain the the missedmessage_hook and message
message_edit_notifications since they are more integration-style.
* There's a slightly subtle change with the missedmessage_hook tests.
Before this commit, we short-circuited the hook if the sender was muted
(5a642cea115be159175d1189f83ba25d2c5c7632).
With this commit, we delegate the check to our dataclass methods.
So, `maybe_enqueue_notifications` will be called even if the sender was
muted, and the test needs to be updated.
* In our test helper `get_maybe_enqueue_notifications_parameters` which
generates default values for testing `maybe_enqueue_notifications` calls,
we keep `message_id`, `sender_id`, and `user_id` as required arguments,
so that the tests are super-clear and avoid accidental false positives.
* Because `do_update_embedded_data` also sends `update_message` events,
we deal with that case with some hacky code for now. See the comment
there.
This mostly completes the extraction of the "when to notify" logic into
our new `notification_data` module.
2021-06-23 14:12:32 +02:00
|
|
|
# Remove fields sent through other pipes to save some space.
|
2021-06-23 10:44:34 +02:00
|
|
|
internal_data.pop("user_id")
|
2021-07-01 17:40:16 +02:00
|
|
|
internal_data["mentioned_user_group_id"] = mentioned_user_group_id
|
2021-06-21 16:48:13 +02:00
|
|
|
extra_user_data[user_profile_id] = dict(internal_data=internal_data)
|
|
|
|
|
|
|
|
# If the message isn't notifiable had the user been idle, then the user
|
|
|
|
# shouldn't receive notifications even if they were online. In that case we can
|
|
|
|
# avoid the more expensive `receiver_is_off_zulip` call, and move on to process
|
|
|
|
# the next user.
|
notifications: Calculate PMs/mentions settings like other settings.
Previously, we checked for the `enable_offline_email_notifications` and
`enable_offline_push_notifications` settings (which determine whether the
user will receive notifications for PMs and mentions) just before sending
notifications. This has a few problem:
1. We do not have access to all the user settings in the notification
handlers (`handle_missedmessage_emails` and `handle_push_notifications`),
and therefore, we cannot correctly determine whether the notification should
be sent. Checks like the following which existed previously, will, for
example, incorrectly not send notifications even when stream email
notifications are enabled-
```
if not receives_offline_email_notifications(user_profile):
return
```
With this commit, we simply do not enqueue notifications if the "offline"
settings are disabled, which fixes that bug.
Additionally, this also fixes a bug with the "online push notifications"
feature, which was, if someone were to:
* turn off notifications for PMs and mentions (`enable_offline_push_notifications`)
* turn on stream push notifications (`enable_stream_push_notifications`)
* turn on "online push" (`enable_online_push_notifications`)
then, they would still receive notifications for PMs when online.
This isn't how the "online push enabled" feature is supposed to work;
it should only act as a wrapper around the other notification settings.
The buggy code was this in `handle_push_notifications`:
```
if not (
receives_offline_push_notifications(user_profile)
or receives_online_push_notifications(user_profile)
):
return
// send notifications
```
This commit removes that code, and extends our `notification_data.py` logic
to cover this case, along with tests.
2. The name for these settings is slightly misleading. They essentially
talk about "what to send notifications for" (PMs and mentions), and not
"when to send notifications" (offline). This commit improves this condition
by restricting the use of this term only to the database field, and using
clearer names everywhere else. This distinction will be important to have
non-confusing code when we implement multiple options for notifications
in the future as dropdown (never/when offline/when offline or online, etc).
3. We should ideally re-check all notification settings just before the
notifications are sent. This is especially important for email notifications,
which may be sent after a long time after the message was sent. We will
in the future add code to thoroughly re-check settings before sending
notifications in a clean manner, but temporarily not re-checking isn't
a terrible scenario either.
2021-07-14 15:34:01 +02:00
|
|
|
if not user_notifications_data.is_notifiable(acting_user_id=sender_id, idle=True):
|
2021-06-06 09:21:09 +02:00
|
|
|
continue
|
2017-09-05 19:55:14 +02:00
|
|
|
|
2021-06-21 16:48:13 +02:00
|
|
|
idle = receiver_is_off_zulip(user_profile_id) or (user_profile_id in presence_idle_user_ids)
|
2021-05-24 06:11:59 +02:00
|
|
|
|
2021-06-21 16:48:13 +02:00
|
|
|
extra_user_data[user_profile_id]["internal_data"].update(
|
|
|
|
maybe_enqueue_notifications(
|
2021-06-25 14:08:41 +02:00
|
|
|
user_notifications_data=user_notifications_data,
|
2021-06-25 13:58:53 +02:00
|
|
|
acting_user_id=sender_id,
|
2021-06-23 12:25:38 +02:00
|
|
|
message_id=message_id,
|
2021-07-01 17:40:16 +02:00
|
|
|
mentioned_user_group_id=mentioned_user_group_id,
|
2021-06-23 12:25:38 +02:00
|
|
|
idle=idle,
|
|
|
|
already_notified={},
|
2021-02-12 08:19:30 +01:00
|
|
|
)
|
2021-06-21 16:48:13 +02:00
|
|
|
)
|
2014-04-24 02:16:53 +02:00
|
|
|
|
2017-09-27 10:09:12 +02:00
|
|
|
for client_data in send_to_clients.values():
|
2021-02-12 08:20:45 +01:00
|
|
|
client = client_data["client"]
|
|
|
|
flags = client_data["flags"]
|
|
|
|
is_sender: bool = client_data.get("is_sender", False)
|
2024-07-12 02:30:23 +02:00
|
|
|
extra_data: Mapping[str, bool] | None = extra_user_data.get(client.user_profile_id, None)
|
2014-04-24 02:16:53 +02:00
|
|
|
|
|
|
|
if not client.accepts_messages():
|
|
|
|
# The actual check is the accepts_event() check below;
|
|
|
|
# this line is just an optimization to avoid copying
|
|
|
|
# message data unnecessarily
|
|
|
|
continue
|
|
|
|
|
2023-11-08 04:53:05 +01:00
|
|
|
can_access_sender = client.user_profile_id not in user_ids_without_access_to_sender
|
|
|
|
message_dict = get_client_payload(
|
|
|
|
client.apply_markdown, client.client_gravatar, can_access_sender
|
|
|
|
)
|
2014-04-24 02:16:53 +02:00
|
|
|
|
|
|
|
# Make sure Zephyr mirroring bots know whether stream is invite-only
|
2014-01-28 18:13:41 +01:00
|
|
|
if "mirror" in client.client_type_name and event_template.get("invite_only"):
|
2014-04-24 02:16:53 +02:00
|
|
|
message_dict = message_dict.copy()
|
|
|
|
message_dict["invite_only_stream"] = True
|
|
|
|
|
2024-07-12 02:30:17 +02:00
|
|
|
user_event: dict[str, Any] = dict(type="message", message=message_dict, flags=flags)
|
2014-04-24 02:16:53 +02:00
|
|
|
if extra_data is not None:
|
|
|
|
user_event.update(extra_data)
|
|
|
|
|
|
|
|
if is_sender:
|
2021-02-12 08:20:45 +01:00
|
|
|
local_message_id = event_template.get("local_id", None)
|
2017-07-14 19:30:23 +02:00
|
|
|
if local_message_id is not None:
|
|
|
|
user_event["local_message_id"] = local_message_id
|
2014-04-24 02:16:53 +02:00
|
|
|
|
|
|
|
if not client.accepts_event(user_event):
|
|
|
|
continue
|
|
|
|
|
|
|
|
# The below prevents (Zephyr) mirroring loops.
|
2021-02-12 08:20:45 +01:00
|
|
|
if "mirror" in sending_client and sending_client.lower() == client.client_type_name.lower():
|
2014-04-24 02:16:53 +02:00
|
|
|
continue
|
2019-08-06 22:34:52 +02:00
|
|
|
|
2014-04-24 02:16:53 +02:00
|
|
|
client.add_event(user_event)
|
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
2020-02-03 17:09:18 +01:00
|
|
|
def process_presence_event(event: Mapping[str, Any], users: Iterable[int]) -> None:
|
2021-02-12 08:20:45 +01:00
|
|
|
if "user_id" not in event:
|
2020-03-03 13:05:09 +01:00
|
|
|
# We only recently added `user_id` to presence data.
|
|
|
|
# Any old events in our queue can just be dropped,
|
|
|
|
# since presence events are pretty ephemeral in nature.
|
2021-02-12 08:20:45 +01:00
|
|
|
logging.warning("Dropping some obsolete presence events after upgrade.")
|
2020-03-03 13:05:09 +01:00
|
|
|
|
2020-02-03 17:09:18 +01:00
|
|
|
slim_event = dict(
|
2021-02-12 08:20:45 +01:00
|
|
|
type="presence",
|
|
|
|
user_id=event["user_id"],
|
|
|
|
server_timestamp=event["server_timestamp"],
|
|
|
|
presence=event["presence"],
|
2020-02-03 17:09:18 +01:00
|
|
|
)
|
|
|
|
|
|
|
|
legacy_event = dict(
|
2021-02-12 08:20:45 +01:00
|
|
|
type="presence",
|
|
|
|
user_id=event["user_id"],
|
|
|
|
email=event["email"],
|
|
|
|
server_timestamp=event["server_timestamp"],
|
|
|
|
presence=event["presence"],
|
2020-02-03 17:09:18 +01:00
|
|
|
)
|
|
|
|
|
|
|
|
for user_profile_id in users:
|
|
|
|
for client in get_client_descriptors_for_user(user_profile_id):
|
|
|
|
if client.accepts_event(event):
|
|
|
|
if client.slim_presence:
|
|
|
|
client.add_event(slim_event)
|
|
|
|
else:
|
|
|
|
client.add_event(legacy_event)
|
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
2017-11-27 11:09:23 +01:00
|
|
|
def process_event(event: Mapping[str, Any], users: Iterable[int]) -> None:
|
2014-04-24 02:16:53 +02:00
|
|
|
for user_profile_id in users:
|
|
|
|
for client in get_client_descriptors_for_user(user_profile_id):
|
|
|
|
if client.accepts_event(event):
|
event_queue: Fix confusing event_queue.push interface.
In e3ad9baf1d1dd862b4e3cd1aae7b3c3067d55752, we introduced yet another
bug where we incorrectly shared event dictionaries between multiple
queues.
Fortunately, the logging that reports on "event was not in the queue"
issues worked and detected this on chat.zulip.org, but this is a clear
indication that the comments we have around this system were not
sufficient to produce correct behavior.
We fix this by changing event_queue.push, the code that mutates the
event dictionaries, to do the shallow copies itself. The only
downside here is process_message_event, a relatively low-traffic code
path, does an extra per-queue dictionary copy. Given that presence,
heartbeat, and message reading events are likely more traffic and
dealing with HTTP is likely much more expensive than a dictionary
copy, this probably doesn't matter performance-wise.
(And if profiling later finds it is, there are potential workarounds
like passing a skip_copy argument we can do).
2020-02-05 20:43:09 +01:00
|
|
|
client.add_event(event)
|
2014-04-24 02:16:53 +02:00
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
2020-06-10 13:47:08 +02:00
|
|
|
def process_deletion_event(event: Mapping[str, Any], users: Iterable[int]) -> None:
|
|
|
|
for user_profile_id in users:
|
|
|
|
for client in get_client_descriptors_for_user(user_profile_id):
|
|
|
|
if not client.accepts_event(event):
|
|
|
|
continue
|
|
|
|
|
|
|
|
# For clients which support message deletion in bulk, we
|
|
|
|
# send a list of msgs_ids together, otherwise we send a
|
|
|
|
# delete event for each message. All clients will be
|
|
|
|
# required to support bulk_message_deletion in the future;
|
|
|
|
# this logic is intended for backwards-compatibility only.
|
|
|
|
if client.bulk_message_deletion:
|
|
|
|
client.add_event(event)
|
|
|
|
continue
|
|
|
|
|
2021-02-12 08:20:45 +01:00
|
|
|
for message_id in event["message_ids"]:
|
2020-06-10 13:47:08 +02:00
|
|
|
# We use the following rather than event.copy()
|
|
|
|
# because the read-only Mapping type doesn't support .copy().
|
|
|
|
compatibility_event = dict(event)
|
2021-02-12 08:20:45 +01:00
|
|
|
compatibility_event["message_id"] = message_id
|
|
|
|
del compatibility_event["message_ids"]
|
2020-06-10 13:47:08 +02:00
|
|
|
client.add_event(compatibility_event)
|
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
|
|
|
def process_message_update_event(
|
|
|
|
orig_event: Mapping[str, Any], users: Iterable[Mapping[str, Any]]
|
|
|
|
) -> None:
|
2020-08-04 02:49:12 +02:00
|
|
|
# Extract the parameters passed via the event object that don't
|
|
|
|
# belong in the actual events.
|
|
|
|
event_template = dict(orig_event)
|
2021-02-12 08:20:45 +01:00
|
|
|
prior_mention_user_ids = set(event_template.pop("prior_mention_user_ids", []))
|
|
|
|
presence_idle_user_ids = set(event_template.pop("presence_idle_user_ids", []))
|
2023-08-04 22:08:17 +02:00
|
|
|
|
|
|
|
# TODO/compatibility: Translation code for the rename of
|
|
|
|
# `pm_mention_push_disabled_user_ids` to `dm_mention_push_disabled_user_ids`.
|
|
|
|
# Remove this when one can no longer directly upgrade from 7.x to main.
|
|
|
|
dm_mention_push_disabled_user_ids = set()
|
|
|
|
if "dm_mention_push_disabled_user_ids" in event_template:
|
|
|
|
dm_mention_push_disabled_user_ids = set(
|
|
|
|
event_template.pop("dm_mention_push_disabled_user_ids")
|
|
|
|
)
|
|
|
|
elif "pm_mention_push_disabled_user_ids" in event_template:
|
|
|
|
dm_mention_push_disabled_user_ids = set(
|
|
|
|
event_template.pop("pm_mention_push_disabled_user_ids")
|
|
|
|
)
|
|
|
|
|
|
|
|
# TODO/compatibility: Translation code for the rename of
|
|
|
|
# `pm_mention_email_disabled_user_ids` to `dm_mention_email_disabled_user_ids`.
|
|
|
|
# Remove this when one can no longer directly upgrade from 7.x to main.
|
|
|
|
dm_mention_email_disabled_user_ids = set()
|
|
|
|
if "dm_mention_email_disabled_user_ids" in event_template:
|
|
|
|
dm_mention_email_disabled_user_ids = set(
|
|
|
|
event_template.pop("dm_mention_email_disabled_user_ids")
|
|
|
|
)
|
|
|
|
elif "pm_mention_email_disabled_user_ids" in event_template:
|
|
|
|
dm_mention_email_disabled_user_ids = set(
|
|
|
|
event_template.pop("pm_mention_email_disabled_user_ids")
|
|
|
|
)
|
|
|
|
|
2021-02-12 08:20:45 +01:00
|
|
|
stream_push_user_ids = set(event_template.pop("stream_push_user_ids", []))
|
|
|
|
stream_email_user_ids = set(event_template.pop("stream_email_user_ids", []))
|
2023-06-07 19:19:33 +02:00
|
|
|
topic_wildcard_mention_user_ids = set(event_template.pop("topic_wildcard_mention_user_ids", []))
|
2023-06-03 16:51:38 +02:00
|
|
|
|
|
|
|
# TODO/compatibility: Translation code for the rename of
|
|
|
|
# `wildcard_mention_user_ids` to `stream_wildcard_mention_user_ids`.
|
|
|
|
# Remove this when one can no longer directly upgrade from 7.x to main.
|
|
|
|
stream_wildcard_mention_user_ids = set()
|
|
|
|
if "stream_wildcard_mention_user_ids" in event_template:
|
|
|
|
stream_wildcard_mention_user_ids = set(
|
|
|
|
event_template.pop("stream_wildcard_mention_user_ids")
|
|
|
|
)
|
|
|
|
elif "wildcard_mention_user_ids" in event_template:
|
|
|
|
stream_wildcard_mention_user_ids = set(event_template.pop("wildcard_mention_user_ids"))
|
|
|
|
|
2023-05-28 17:03:04 +02:00
|
|
|
followed_topic_push_user_ids = set(event_template.pop("followed_topic_push_user_ids", []))
|
2023-05-17 16:01:16 +02:00
|
|
|
followed_topic_email_user_ids = set(event_template.pop("followed_topic_email_user_ids", []))
|
2023-06-07 19:19:33 +02:00
|
|
|
topic_wildcard_mention_in_followed_topic_user_ids = set(
|
|
|
|
event_template.pop("topic_wildcard_mention_in_followed_topic_user_ids", [])
|
|
|
|
)
|
2023-06-03 16:51:38 +02:00
|
|
|
stream_wildcard_mention_in_followed_topic_user_ids = set(
|
|
|
|
event_template.pop("stream_wildcard_mention_in_followed_topic_user_ids", [])
|
2023-06-02 09:42:58 +02:00
|
|
|
)
|
2021-06-06 09:21:09 +02:00
|
|
|
muted_sender_user_ids = set(event_template.pop("muted_sender_user_ids", []))
|
2021-12-19 12:04:36 +01:00
|
|
|
all_bot_user_ids = set(event_template.pop("all_bot_user_ids", []))
|
2022-10-22 13:25:06 +02:00
|
|
|
disable_external_notifications = event_template.pop("disable_external_notifications", False)
|
2021-05-24 05:57:59 +02:00
|
|
|
|
|
|
|
# TODO/compatibility: Translation code for the rename of
|
|
|
|
# `push_notify_user_ids` to `online_push_user_ids`. Remove this
|
2021-09-01 00:15:31 +02:00
|
|
|
# when one can no longer directly upgrade from 4.x to main.
|
2021-05-24 05:57:59 +02:00
|
|
|
online_push_user_ids = set()
|
|
|
|
if "online_push_user_ids" in event_template:
|
|
|
|
online_push_user_ids = set(event_template.pop("online_push_user_ids"))
|
|
|
|
elif "push_notify_user_ids" in event_template:
|
|
|
|
online_push_user_ids = set(event_template.pop("push_notify_user_ids"))
|
Notify offline users about edited stream messages.
We now do push notifications and missed message emails
for offline users who are subscribed to the stream for
a message that has been edited, but we short circuit
the offline-notification logic for any user who presumably
would have already received a notification on the original
message.
This effectively boils down to sending notifications to newly
mentioned users. The motivating use case here is that you
forget to mention somebody in a message, and then you edit
the message to mention the person. If they are offline, they
will now get pushed notifications and missed message emails,
with some minor caveats.
We try to mostly use the same techniques here as the
send-message code path, and we share common code with the
send-message path once we get to the Tornado layer and call
maybe_enqueue_notifications.
The major places where we differ are in a function called
maybe_enqueue_notifications_for_message_update, and the top
of that function short circuits a bunch of cases where we
can mostly assume that the original message had an offline
notification.
We can expect a couple changes in the future:
* Requirements may change here, and it might make sense
to send offline notifications on the update side even
in circumstances where the original message had a
notification.
* We may track more notifications in a DB model, which
may simplify our short-circuit logic.
In the view/action layer, we already had two separate codepaths
for send-message and update-message, but this mostly echoes
what the send-message path does in terms of collecting data
about recipients.
2017-10-03 16:25:12 +02:00
|
|
|
|
2021-02-12 08:20:45 +01:00
|
|
|
stream_name = event_template.get("stream_name")
|
|
|
|
message_id = event_template["message_id"]
|
Notify offline users about edited stream messages.
We now do push notifications and missed message emails
for offline users who are subscribed to the stream for
a message that has been edited, but we short circuit
the offline-notification logic for any user who presumably
would have already received a notification on the original
message.
This effectively boils down to sending notifications to newly
mentioned users. The motivating use case here is that you
forget to mention somebody in a message, and then you edit
the message to mention the person. If they are offline, they
will now get pushed notifications and missed message emails,
with some minor caveats.
We try to mostly use the same techniques here as the
send-message code path, and we share common code with the
send-message path once we get to the Tornado layer and call
maybe_enqueue_notifications.
The major places where we differ are in a function called
maybe_enqueue_notifications_for_message_update, and the top
of that function short circuits a bunch of cases where we
can mostly assume that the original message had an offline
notification.
We can expect a couple changes in the future:
* Requirements may change here, and it might make sense
to send offline notifications on the update side even
in circumstances where the original message had a
notification.
* We may track more notifications in a DB model, which
may simplify our short-circuit logic.
In the view/action layer, we already had two separate codepaths
for send-message and update-message, but this mostly echoes
what the send-message path does in terms of collecting data
about recipients.
2017-10-03 16:25:12 +02:00
|
|
|
|
2022-04-18 13:35:18 +02:00
|
|
|
# TODO/compatibility: Modern `update_message` events contain the
|
|
|
|
# rendering_only key, which indicates whether the update is a link
|
|
|
|
# preview rendering update (not a human action). However, because
|
|
|
|
# events may be in the notify_tornado queue at the time we
|
|
|
|
# upgrade, we need the below logic to compute rendering_only based
|
|
|
|
# on the `user_id` key not being present in legacy events that
|
|
|
|
# would have had rendering_only set. Remove this check when one
|
|
|
|
# can no longer directly update from 4.x to main.
|
|
|
|
if "rendering_only" in event_template:
|
|
|
|
rendering_only_update = event_template["rendering_only"]
|
|
|
|
else:
|
|
|
|
rendering_only_update = "user_id" not in event_template
|
|
|
|
|
Notify offline users about edited stream messages.
We now do push notifications and missed message emails
for offline users who are subscribed to the stream for
a message that has been edited, but we short circuit
the offline-notification logic for any user who presumably
would have already received a notification on the original
message.
This effectively boils down to sending notifications to newly
mentioned users. The motivating use case here is that you
forget to mention somebody in a message, and then you edit
the message to mention the person. If they are offline, they
will now get pushed notifications and missed message emails,
with some minor caveats.
We try to mostly use the same techniques here as the
send-message code path, and we share common code with the
send-message path once we get to the Tornado layer and call
maybe_enqueue_notifications.
The major places where we differ are in a function called
maybe_enqueue_notifications_for_message_update, and the top
of that function short circuits a bunch of cases where we
can mostly assume that the original message had an offline
notification.
We can expect a couple changes in the future:
* Requirements may change here, and it might make sense
to send offline notifications on the update side even
in circumstances where the original message had a
notification.
* We may track more notifications in a DB model, which
may simplify our short-circuit logic.
In the view/action layer, we already had two separate codepaths
for send-message and update-message, but this mostly echoes
what the send-message path does in terms of collecting data
about recipients.
2017-10-03 16:25:12 +02:00
|
|
|
for user_data in users:
|
2021-02-12 08:20:45 +01:00
|
|
|
user_profile_id = user_data["id"]
|
maybe_enqueue_notifications: Take in notification_data dataclass.
* Modify `maybe_enqueue_notifications` to take in an instance of the
dataclass introduced in 951b49c048ba3464e74ad7965da3453fe36d0a96.
* The `check_notify` tests tested the "when to notify" logic in a way
which involved `maybe_enqueue_notifications`. To simplify things, we've
earlier extracted this logic in 8182632d7e9f8490b9b9295e01b5912dcf173fd5.
So, we just kill off the `check_notify` test, and keep only those parts
which verify the queueing and return value behavior of that funtion.
* We retain the the missedmessage_hook and message
message_edit_notifications since they are more integration-style.
* There's a slightly subtle change with the missedmessage_hook tests.
Before this commit, we short-circuited the hook if the sender was muted
(5a642cea115be159175d1189f83ba25d2c5c7632).
With this commit, we delegate the check to our dataclass methods.
So, `maybe_enqueue_notifications` will be called even if the sender was
muted, and the test needs to be updated.
* In our test helper `get_maybe_enqueue_notifications_parameters` which
generates default values for testing `maybe_enqueue_notifications` calls,
we keep `message_id`, `sender_id`, and `user_id` as required arguments,
so that the tests are super-clear and avoid accidental false positives.
* Because `do_update_embedded_data` also sends `update_message` events,
we deal with that case with some hacky code for now. See the comment
there.
This mostly completes the extraction of the "when to notify" logic into
our new `notification_data` module.
2021-06-23 14:12:32 +02:00
|
|
|
|
Notify offline users about edited stream messages.
We now do push notifications and missed message emails
for offline users who are subscribed to the stream for
a message that has been edited, but we short circuit
the offline-notification logic for any user who presumably
would have already received a notification on the original
message.
This effectively boils down to sending notifications to newly
mentioned users. The motivating use case here is that you
forget to mention somebody in a message, and then you edit
the message to mention the person. If they are offline, they
will now get pushed notifications and missed message emails,
with some minor caveats.
We try to mostly use the same techniques here as the
send-message code path, and we share common code with the
send-message path once we get to the Tornado layer and call
maybe_enqueue_notifications.
The major places where we differ are in a function called
maybe_enqueue_notifications_for_message_update, and the top
of that function short circuits a bunch of cases where we
can mostly assume that the original message had an offline
notification.
We can expect a couple changes in the future:
* Requirements may change here, and it might make sense
to send offline notifications on the update side even
in circumstances where the original message had a
notification.
* We may track more notifications in a DB model, which
may simplify our short-circuit logic.
In the view/action layer, we already had two separate codepaths
for send-message and update-message, but this mostly echoes
what the send-message path does in terms of collecting data
about recipients.
2017-10-03 16:25:12 +02:00
|
|
|
user_event = dict(event_template) # shallow copy, but deep enough for our needs
|
2022-12-12 03:39:16 +01:00
|
|
|
for key in user_data:
|
Notify offline users about edited stream messages.
We now do push notifications and missed message emails
for offline users who are subscribed to the stream for
a message that has been edited, but we short circuit
the offline-notification logic for any user who presumably
would have already received a notification on the original
message.
This effectively boils down to sending notifications to newly
mentioned users. The motivating use case here is that you
forget to mention somebody in a message, and then you edit
the message to mention the person. If they are offline, they
will now get pushed notifications and missed message emails,
with some minor caveats.
We try to mostly use the same techniques here as the
send-message code path, and we share common code with the
send-message path once we get to the Tornado layer and call
maybe_enqueue_notifications.
The major places where we differ are in a function called
maybe_enqueue_notifications_for_message_update, and the top
of that function short circuits a bunch of cases where we
can mostly assume that the original message had an offline
notification.
We can expect a couple changes in the future:
* Requirements may change here, and it might make sense
to send offline notifications on the update side even
in circumstances where the original message had a
notification.
* We may track more notifications in a DB model, which
may simplify our short-circuit logic.
In the view/action layer, we already had two separate codepaths
for send-message and update-message, but this mostly echoes
what the send-message path does in terms of collecting data
about recipients.
2017-10-03 16:25:12 +02:00
|
|
|
if key != "id":
|
|
|
|
user_event[key] = user_data[key]
|
2021-06-22 13:40:48 +02:00
|
|
|
|
2022-04-18 13:35:18 +02:00
|
|
|
# Events where `rendering_only_update` is True come from the
|
|
|
|
# do_update_embedded_data code path, and represent rendering
|
|
|
|
# previews; there should be no real content changes.
|
|
|
|
# Therefore, we know only events where `rendering_only_update`
|
|
|
|
# is False possibly send notifications.
|
|
|
|
if not rendering_only_update:
|
|
|
|
# The user we'll get here will be the sender if the message's
|
|
|
|
# content was edited, and the editor for topic edits. That's
|
|
|
|
# the correct "acting_user" for both cases.
|
|
|
|
acting_user_id = event_template["user_id"]
|
|
|
|
|
|
|
|
flags: Collection[str] = user_event["flags"]
|
|
|
|
user_notifications_data = UserMessageNotificationsData.from_user_id_sets(
|
|
|
|
user_id=user_profile_id,
|
|
|
|
flags=flags,
|
2023-09-12 21:10:57 +02:00
|
|
|
private_message=stream_name is None,
|
2022-10-22 13:25:06 +02:00
|
|
|
disable_external_notifications=disable_external_notifications,
|
2022-04-18 13:35:18 +02:00
|
|
|
online_push_user_ids=online_push_user_ids,
|
2023-08-04 22:08:17 +02:00
|
|
|
dm_mention_push_disabled_user_ids=dm_mention_push_disabled_user_ids,
|
|
|
|
dm_mention_email_disabled_user_ids=dm_mention_email_disabled_user_ids,
|
2022-04-18 13:35:18 +02:00
|
|
|
stream_push_user_ids=stream_push_user_ids,
|
|
|
|
stream_email_user_ids=stream_email_user_ids,
|
2023-06-07 19:19:33 +02:00
|
|
|
topic_wildcard_mention_user_ids=topic_wildcard_mention_user_ids,
|
2023-06-03 16:51:38 +02:00
|
|
|
stream_wildcard_mention_user_ids=stream_wildcard_mention_user_ids,
|
2023-05-28 17:03:04 +02:00
|
|
|
followed_topic_push_user_ids=followed_topic_push_user_ids,
|
2023-05-17 16:01:16 +02:00
|
|
|
followed_topic_email_user_ids=followed_topic_email_user_ids,
|
2023-06-07 19:19:33 +02:00
|
|
|
topic_wildcard_mention_in_followed_topic_user_ids=topic_wildcard_mention_in_followed_topic_user_ids,
|
2023-06-03 16:51:38 +02:00
|
|
|
stream_wildcard_mention_in_followed_topic_user_ids=stream_wildcard_mention_in_followed_topic_user_ids,
|
2022-04-18 13:35:18 +02:00
|
|
|
muted_sender_user_ids=muted_sender_user_ids,
|
|
|
|
all_bot_user_ids=all_bot_user_ids,
|
|
|
|
)
|
|
|
|
|
|
|
|
maybe_enqueue_notifications_for_message_update(
|
|
|
|
user_notifications_data=user_notifications_data,
|
|
|
|
message_id=message_id,
|
|
|
|
acting_user_id=acting_user_id,
|
2023-09-12 21:10:57 +02:00
|
|
|
private_message=stream_name is None,
|
|
|
|
presence_idle=user_profile_id in presence_idle_user_ids,
|
|
|
|
prior_mentioned=user_profile_id in prior_mention_user_ids,
|
2022-04-18 13:35:18 +02:00
|
|
|
)
|
Notify offline users about edited stream messages.
We now do push notifications and missed message emails
for offline users who are subscribed to the stream for
a message that has been edited, but we short circuit
the offline-notification logic for any user who presumably
would have already received a notification on the original
message.
This effectively boils down to sending notifications to newly
mentioned users. The motivating use case here is that you
forget to mention somebody in a message, and then you edit
the message to mention the person. If they are offline, they
will now get pushed notifications and missed message emails,
with some minor caveats.
We try to mostly use the same techniques here as the
send-message code path, and we share common code with the
send-message path once we get to the Tornado layer and call
maybe_enqueue_notifications.
The major places where we differ are in a function called
maybe_enqueue_notifications_for_message_update, and the top
of that function short circuits a bunch of cases where we
can mostly assume that the original message had an offline
notification.
We can expect a couple changes in the future:
* Requirements may change here, and it might make sense
to send offline notifications on the update side even
in circumstances where the original message had a
notification.
* We may track more notifications in a DB model, which
may simplify our short-circuit logic.
In the view/action layer, we already had two separate codepaths
for send-message and update-message, but this mostly echoes
what the send-message path does in terms of collecting data
about recipients.
2017-10-03 16:25:12 +02:00
|
|
|
|
|
|
|
for client in get_client_descriptors_for_user(user_profile_id):
|
|
|
|
if client.accepts_event(user_event):
|
2019-08-06 22:34:52 +02:00
|
|
|
# We need to do another shallow copy, or we risk
|
|
|
|
# sending the same event to multiple clients.
|
event_queue: Fix confusing event_queue.push interface.
In e3ad9baf1d1dd862b4e3cd1aae7b3c3067d55752, we introduced yet another
bug where we incorrectly shared event dictionaries between multiple
queues.
Fortunately, the logging that reports on "event was not in the queue"
issues worked and detected this on chat.zulip.org, but this is a clear
indication that the comments we have around this system were not
sufficient to produce correct behavior.
We fix this by changing event_queue.push, the code that mutates the
event dictionaries, to do the shallow copies itself. The only
downside here is process_message_event, a relatively low-traffic code
path, does an extra per-queue dictionary copy. Given that presence,
heartbeat, and message reading events are likely more traffic and
dealing with HTTP is likely much more expensive than a dictionary
copy, this probably doesn't matter performance-wise.
(And if profiling later finds it is, there are potential workarounds
like passing a skip_copy argument we can do).
2020-02-05 20:43:09 +01:00
|
|
|
client.add_event(user_event)
|
Notify offline users about edited stream messages.
We now do push notifications and missed message emails
for offline users who are subscribed to the stream for
a message that has been edited, but we short circuit
the offline-notification logic for any user who presumably
would have already received a notification on the original
message.
This effectively boils down to sending notifications to newly
mentioned users. The motivating use case here is that you
forget to mention somebody in a message, and then you edit
the message to mention the person. If they are offline, they
will now get pushed notifications and missed message emails,
with some minor caveats.
We try to mostly use the same techniques here as the
send-message code path, and we share common code with the
send-message path once we get to the Tornado layer and call
maybe_enqueue_notifications.
The major places where we differ are in a function called
maybe_enqueue_notifications_for_message_update, and the top
of that function short circuits a bunch of cases where we
can mostly assume that the original message had an offline
notification.
We can expect a couple changes in the future:
* Requirements may change here, and it might make sense
to send offline notifications on the update side even
in circumstances where the original message had a
notification.
* We may track more notifications in a DB model, which
may simplify our short-circuit logic.
In the view/action layer, we already had two separate codepaths
for send-message and update-message, but this mostly echoes
what the send-message path does in terms of collecting data
about recipients.
2017-10-03 16:25:12 +02:00
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
2022-10-27 19:05:10 +02:00
|
|
|
def process_custom_profile_fields_event(event: Mapping[str, Any], users: Iterable[int]) -> None:
|
|
|
|
pronouns_type_unsupported_fields = copy.deepcopy(event["fields"])
|
|
|
|
for field in pronouns_type_unsupported_fields:
|
|
|
|
if field["type"] == CustomProfileField.PRONOUNS:
|
|
|
|
field["type"] = CustomProfileField.SHORT_TEXT
|
|
|
|
|
|
|
|
pronouns_type_unsupported_event = dict(
|
|
|
|
type="custom_profile_fields", fields=pronouns_type_unsupported_fields
|
|
|
|
)
|
|
|
|
|
|
|
|
for user_profile_id in users:
|
|
|
|
for client in get_client_descriptors_for_user(user_profile_id):
|
|
|
|
if client.accepts_event(event):
|
|
|
|
if not client.pronouns_field_type_supported:
|
|
|
|
client.add_event(pronouns_type_unsupported_event)
|
|
|
|
continue
|
|
|
|
client.add_event(event)
|
|
|
|
|
|
|
|
|
2023-10-24 19:47:39 +02:00
|
|
|
def process_realm_user_add_event(event: Mapping[str, Any], users: Iterable[int]) -> None:
|
|
|
|
user_add_event = dict(event)
|
|
|
|
event_for_inaccessible_user = user_add_event.pop("inaccessible_user", False)
|
|
|
|
for user_profile_id in users:
|
|
|
|
for client in get_client_descriptors_for_user(user_profile_id):
|
|
|
|
if client.accepts_event(user_add_event):
|
|
|
|
if event_for_inaccessible_user and client.user_list_incomplete:
|
|
|
|
continue
|
|
|
|
client.add_event(user_add_event)
|
|
|
|
|
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
def maybe_enqueue_notifications_for_message_update(
|
2021-06-25 14:08:41 +02:00
|
|
|
user_notifications_data: UserMessageNotificationsData,
|
2021-02-12 08:19:30 +01:00
|
|
|
message_id: int,
|
2021-06-25 13:58:53 +02:00
|
|
|
acting_user_id: int,
|
2021-06-07 12:43:39 +02:00
|
|
|
private_message: bool,
|
2021-06-07 12:58:21 +02:00
|
|
|
presence_idle: bool,
|
|
|
|
prior_mentioned: bool,
|
2021-02-12 08:19:30 +01:00
|
|
|
) -> None:
|
2021-06-25 14:08:41 +02:00
|
|
|
if user_notifications_data.sender_is_muted:
|
2021-06-06 09:21:09 +02:00
|
|
|
# Never send notifications if the sender has been muted
|
|
|
|
return
|
|
|
|
|
Notify offline users about edited stream messages.
We now do push notifications and missed message emails
for offline users who are subscribed to the stream for
a message that has been edited, but we short circuit
the offline-notification logic for any user who presumably
would have already received a notification on the original
message.
This effectively boils down to sending notifications to newly
mentioned users. The motivating use case here is that you
forget to mention somebody in a message, and then you edit
the message to mention the person. If they are offline, they
will now get pushed notifications and missed message emails,
with some minor caveats.
We try to mostly use the same techniques here as the
send-message code path, and we share common code with the
send-message path once we get to the Tornado layer and call
maybe_enqueue_notifications.
The major places where we differ are in a function called
maybe_enqueue_notifications_for_message_update, and the top
of that function short circuits a bunch of cases where we
can mostly assume that the original message had an offline
notification.
We can expect a couple changes in the future:
* Requirements may change here, and it might make sense
to send offline notifications on the update side even
in circumstances where the original message had a
notification.
* We may track more notifications in a DB model, which
may simplify our short-circuit logic.
In the view/action layer, we already had two separate codepaths
for send-message and update-message, but this mostly echoes
what the send-message path does in terms of collecting data
about recipients.
2017-10-03 16:25:12 +02:00
|
|
|
if private_message:
|
2023-06-19 16:42:11 +02:00
|
|
|
# We don't do offline notifications for direct messages,
|
|
|
|
# because we already notified the user of the original
|
|
|
|
# message.
|
Notify offline users about edited stream messages.
We now do push notifications and missed message emails
for offline users who are subscribed to the stream for
a message that has been edited, but we short circuit
the offline-notification logic for any user who presumably
would have already received a notification on the original
message.
This effectively boils down to sending notifications to newly
mentioned users. The motivating use case here is that you
forget to mention somebody in a message, and then you edit
the message to mention the person. If they are offline, they
will now get pushed notifications and missed message emails,
with some minor caveats.
We try to mostly use the same techniques here as the
send-message code path, and we share common code with the
send-message path once we get to the Tornado layer and call
maybe_enqueue_notifications.
The major places where we differ are in a function called
maybe_enqueue_notifications_for_message_update, and the top
of that function short circuits a bunch of cases where we
can mostly assume that the original message had an offline
notification.
We can expect a couple changes in the future:
* Requirements may change here, and it might make sense
to send offline notifications on the update side even
in circumstances where the original message had a
notification.
* We may track more notifications in a DB model, which
may simplify our short-circuit logic.
In the view/action layer, we already had two separate codepaths
for send-message and update-message, but this mostly echoes
what the send-message path does in terms of collecting data
about recipients.
2017-10-03 16:25:12 +02:00
|
|
|
return
|
|
|
|
|
2021-06-07 12:58:21 +02:00
|
|
|
if prior_mentioned:
|
Notify offline users about edited stream messages.
We now do push notifications and missed message emails
for offline users who are subscribed to the stream for
a message that has been edited, but we short circuit
the offline-notification logic for any user who presumably
would have already received a notification on the original
message.
This effectively boils down to sending notifications to newly
mentioned users. The motivating use case here is that you
forget to mention somebody in a message, and then you edit
the message to mention the person. If they are offline, they
will now get pushed notifications and missed message emails,
with some minor caveats.
We try to mostly use the same techniques here as the
send-message code path, and we share common code with the
send-message path once we get to the Tornado layer and call
maybe_enqueue_notifications.
The major places where we differ are in a function called
maybe_enqueue_notifications_for_message_update, and the top
of that function short circuits a bunch of cases where we
can mostly assume that the original message had an offline
notification.
We can expect a couple changes in the future:
* Requirements may change here, and it might make sense
to send offline notifications on the update side even
in circumstances where the original message had a
notification.
* We may track more notifications in a DB model, which
may simplify our short-circuit logic.
In the view/action layer, we already had two separate codepaths
for send-message and update-message, but this mostly echoes
what the send-message path does in terms of collecting data
about recipients.
2017-10-03 16:25:12 +02:00
|
|
|
# Don't spam people with duplicate mentions. This is
|
|
|
|
# especially important considering that most message
|
|
|
|
# edits are simple typo corrections.
|
2019-08-26 04:40:07 +02:00
|
|
|
#
|
|
|
|
# Note that prior_mention_user_ids contains users who received
|
|
|
|
# a wildcard mention as well as normal mentions.
|
2019-09-03 23:27:45 +02:00
|
|
|
#
|
|
|
|
# TODO: Ideally, that would mean that we exclude here cases
|
|
|
|
# where user_profile.wildcard_mentions_notify=False and have
|
|
|
|
# those still send a notification. However, we don't have the
|
|
|
|
# data to determine whether or not that was the case at the
|
|
|
|
# time the original message was sent, so we can't do that
|
|
|
|
# without extending the UserMessage data model.
|
Notify offline users about edited stream messages.
We now do push notifications and missed message emails
for offline users who are subscribed to the stream for
a message that has been edited, but we short circuit
the offline-notification logic for any user who presumably
would have already received a notification on the original
message.
This effectively boils down to sending notifications to newly
mentioned users. The motivating use case here is that you
forget to mention somebody in a message, and then you edit
the message to mention the person. If they are offline, they
will now get pushed notifications and missed message emails,
with some minor caveats.
We try to mostly use the same techniques here as the
send-message code path, and we share common code with the
send-message path once we get to the Tornado layer and call
maybe_enqueue_notifications.
The major places where we differ are in a function called
maybe_enqueue_notifications_for_message_update, and the top
of that function short circuits a bunch of cases where we
can mostly assume that the original message had an offline
notification.
We can expect a couple changes in the future:
* Requirements may change here, and it might make sense
to send offline notifications on the update side even
in circumstances where the original message had a
notification.
* We may track more notifications in a DB model, which
may simplify our short-circuit logic.
In the view/action layer, we already had two separate codepaths
for send-message and update-message, but this mostly echoes
what the send-message path does in terms of collecting data
about recipients.
2017-10-03 16:25:12 +02:00
|
|
|
return
|
|
|
|
|
2023-05-17 16:01:16 +02:00
|
|
|
if (
|
|
|
|
user_notifications_data.stream_push_notify
|
|
|
|
or user_notifications_data.stream_email_notify
|
2023-05-28 17:03:04 +02:00
|
|
|
or user_notifications_data.followed_topic_push_notify
|
2023-05-17 16:01:16 +02:00
|
|
|
or user_notifications_data.followed_topic_email_notify
|
|
|
|
):
|
Notify offline users about edited stream messages.
We now do push notifications and missed message emails
for offline users who are subscribed to the stream for
a message that has been edited, but we short circuit
the offline-notification logic for any user who presumably
would have already received a notification on the original
message.
This effectively boils down to sending notifications to newly
mentioned users. The motivating use case here is that you
forget to mention somebody in a message, and then you edit
the message to mention the person. If they are offline, they
will now get pushed notifications and missed message emails,
with some minor caveats.
We try to mostly use the same techniques here as the
send-message code path, and we share common code with the
send-message path once we get to the Tornado layer and call
maybe_enqueue_notifications.
The major places where we differ are in a function called
maybe_enqueue_notifications_for_message_update, and the top
of that function short circuits a bunch of cases where we
can mostly assume that the original message had an offline
notification.
We can expect a couple changes in the future:
* Requirements may change here, and it might make sense
to send offline notifications on the update side even
in circumstances where the original message had a
notification.
* We may track more notifications in a DB model, which
may simplify our short-circuit logic.
In the view/action layer, we already had two separate codepaths
for send-message and update-message, but this mostly echoes
what the send-message path does in terms of collecting data
about recipients.
2017-10-03 16:25:12 +02:00
|
|
|
# Currently we assume that if this flag is set to True, then
|
|
|
|
# the user already was notified about the earlier message,
|
|
|
|
# so we short circuit. We may handle this more rigorously
|
|
|
|
# in the future by looking at something like an AlreadyNotified
|
|
|
|
# model.
|
|
|
|
return
|
|
|
|
|
2021-06-25 14:08:41 +02:00
|
|
|
idle = presence_idle or receiver_is_off_zulip(user_notifications_data.user_id)
|
Notify offline users about edited stream messages.
We now do push notifications and missed message emails
for offline users who are subscribed to the stream for
a message that has been edited, but we short circuit
the offline-notification logic for any user who presumably
would have already received a notification on the original
message.
This effectively boils down to sending notifications to newly
mentioned users. The motivating use case here is that you
forget to mention somebody in a message, and then you edit
the message to mention the person. If they are offline, they
will now get pushed notifications and missed message emails,
with some minor caveats.
We try to mostly use the same techniques here as the
send-message code path, and we share common code with the
send-message path once we get to the Tornado layer and call
maybe_enqueue_notifications.
The major places where we differ are in a function called
maybe_enqueue_notifications_for_message_update, and the top
of that function short circuits a bunch of cases where we
can mostly assume that the original message had an offline
notification.
We can expect a couple changes in the future:
* Requirements may change here, and it might make sense
to send offline notifications on the update side even
in circumstances where the original message had a
notification.
* We may track more notifications in a DB model, which
may simplify our short-circuit logic.
In the view/action layer, we already had two separate codepaths
for send-message and update-message, but this mostly echoes
what the send-message path does in terms of collecting data
about recipients.
2017-10-03 16:25:12 +02:00
|
|
|
|
2021-07-01 17:40:16 +02:00
|
|
|
# We don't yet support custom user group mentions for message edit notifications.
|
|
|
|
# Users will still receive notifications (because of the mentioned flag), but those
|
|
|
|
# will be as if they were mentioned personally.
|
|
|
|
mentioned_user_group_id = None
|
|
|
|
|
Notify offline users about edited stream messages.
We now do push notifications and missed message emails
for offline users who are subscribed to the stream for
a message that has been edited, but we short circuit
the offline-notification logic for any user who presumably
would have already received a notification on the original
message.
This effectively boils down to sending notifications to newly
mentioned users. The motivating use case here is that you
forget to mention somebody in a message, and then you edit
the message to mention the person. If they are offline, they
will now get pushed notifications and missed message emails,
with some minor caveats.
We try to mostly use the same techniques here as the
send-message code path, and we share common code with the
send-message path once we get to the Tornado layer and call
maybe_enqueue_notifications.
The major places where we differ are in a function called
maybe_enqueue_notifications_for_message_update, and the top
of that function short circuits a bunch of cases where we
can mostly assume that the original message had an offline
notification.
We can expect a couple changes in the future:
* Requirements may change here, and it might make sense
to send offline notifications on the update side even
in circumstances where the original message had a
notification.
* We may track more notifications in a DB model, which
may simplify our short-circuit logic.
In the view/action layer, we already had two separate codepaths
for send-message and update-message, but this mostly echoes
what the send-message path does in terms of collecting data
about recipients.
2017-10-03 16:25:12 +02:00
|
|
|
maybe_enqueue_notifications(
|
2021-06-25 14:08:41 +02:00
|
|
|
user_notifications_data=user_notifications_data,
|
Notify offline users about edited stream messages.
We now do push notifications and missed message emails
for offline users who are subscribed to the stream for
a message that has been edited, but we short circuit
the offline-notification logic for any user who presumably
would have already received a notification on the original
message.
This effectively boils down to sending notifications to newly
mentioned users. The motivating use case here is that you
forget to mention somebody in a message, and then you edit
the message to mention the person. If they are offline, they
will now get pushed notifications and missed message emails,
with some minor caveats.
We try to mostly use the same techniques here as the
send-message code path, and we share common code with the
send-message path once we get to the Tornado layer and call
maybe_enqueue_notifications.
The major places where we differ are in a function called
maybe_enqueue_notifications_for_message_update, and the top
of that function short circuits a bunch of cases where we
can mostly assume that the original message had an offline
notification.
We can expect a couple changes in the future:
* Requirements may change here, and it might make sense
to send offline notifications on the update side even
in circumstances where the original message had a
notification.
* We may track more notifications in a DB model, which
may simplify our short-circuit logic.
In the view/action layer, we already had two separate codepaths
for send-message and update-message, but this mostly echoes
what the send-message path does in terms of collecting data
about recipients.
2017-10-03 16:25:12 +02:00
|
|
|
message_id=message_id,
|
2021-06-25 13:58:53 +02:00
|
|
|
acting_user_id=acting_user_id,
|
2021-07-01 17:40:16 +02:00
|
|
|
mentioned_user_group_id=mentioned_user_group_id,
|
Notify offline users about edited stream messages.
We now do push notifications and missed message emails
for offline users who are subscribed to the stream for
a message that has been edited, but we short circuit
the offline-notification logic for any user who presumably
would have already received a notification on the original
message.
This effectively boils down to sending notifications to newly
mentioned users. The motivating use case here is that you
forget to mention somebody in a message, and then you edit
the message to mention the person. If they are offline, they
will now get pushed notifications and missed message emails,
with some minor caveats.
We try to mostly use the same techniques here as the
send-message code path, and we share common code with the
send-message path once we get to the Tornado layer and call
maybe_enqueue_notifications.
The major places where we differ are in a function called
maybe_enqueue_notifications_for_message_update, and the top
of that function short circuits a bunch of cases where we
can mostly assume that the original message had an offline
notification.
We can expect a couple changes in the future:
* Requirements may change here, and it might make sense
to send offline notifications on the update side even
in circumstances where the original message had a
notification.
* We may track more notifications in a DB model, which
may simplify our short-circuit logic.
In the view/action layer, we already had two separate codepaths
for send-message and update-message, but this mostly echoes
what the send-message path does in terms of collecting data
about recipients.
2017-10-03 16:25:12 +02:00
|
|
|
idle=idle,
|
2017-10-18 06:54:03 +02:00
|
|
|
already_notified={},
|
Notify offline users about edited stream messages.
We now do push notifications and missed message emails
for offline users who are subscribed to the stream for
a message that has been edited, but we short circuit
the offline-notification logic for any user who presumably
would have already received a notification on the original
message.
This effectively boils down to sending notifications to newly
mentioned users. The motivating use case here is that you
forget to mention somebody in a message, and then you edit
the message to mention the person. If they are offline, they
will now get pushed notifications and missed message emails,
with some minor caveats.
We try to mostly use the same techniques here as the
send-message code path, and we share common code with the
send-message path once we get to the Tornado layer and call
maybe_enqueue_notifications.
The major places where we differ are in a function called
maybe_enqueue_notifications_for_message_update, and the top
of that function short circuits a bunch of cases where we
can mostly assume that the original message had an offline
notification.
We can expect a couple changes in the future:
* Requirements may change here, and it might make sense
to send offline notifications on the update side even
in circumstances where the original message had a
notification.
* We may track more notifications in a DB model, which
may simplify our short-circuit logic.
In the view/action layer, we already had two separate codepaths
for send-message and update-message, but this mostly echoes
what the send-message path does in terms of collecting data
about recipients.
2017-10-03 16:25:12 +02:00
|
|
|
)
|
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
2021-06-18 19:30:57 +02:00
|
|
|
def reformat_legacy_send_message_event(
|
2024-07-12 02:30:23 +02:00
|
|
|
event: Mapping[str, Any], users: list[int] | list[Mapping[str, Any]]
|
2024-07-12 02:30:17 +02:00
|
|
|
) -> tuple[MutableMapping[str, Any], Collection[MutableMapping[str, Any]]]:
|
2021-06-18 19:30:57 +02:00
|
|
|
# do_send_messages used to send events with users in dict format, with the
|
|
|
|
# dict containing the user_id and other data. We later trimmed down the user
|
|
|
|
# data to only contain the user_id and the usermessage flags, and put everything
|
|
|
|
# else in the event dict as lists.
|
|
|
|
# This block handles any old-format events still in the queue during upgrade.
|
|
|
|
|
|
|
|
modern_event = cast(MutableMapping[str, Any], event)
|
2024-07-12 02:30:17 +02:00
|
|
|
user_dicts = cast(list[MutableMapping[str, Any]], users)
|
2021-06-18 19:30:57 +02:00
|
|
|
|
|
|
|
# Back-calculate the older all-booleans format data in the `users` dicts into the newer
|
|
|
|
# all-lists format, and attach the lists to the `event` object.
|
|
|
|
modern_event["online_push_user_ids"] = []
|
|
|
|
modern_event["stream_push_user_ids"] = []
|
|
|
|
modern_event["stream_email_user_ids"] = []
|
2023-06-03 16:51:38 +02:00
|
|
|
modern_event["stream_wildcard_mention_user_ids"] = []
|
2021-06-18 19:30:57 +02:00
|
|
|
modern_event["muted_sender_user_ids"] = []
|
|
|
|
|
|
|
|
for user in user_dicts:
|
|
|
|
user_id = user["id"]
|
|
|
|
|
|
|
|
if user.pop("stream_push_notify", False):
|
|
|
|
modern_event["stream_push_user_ids"].append(user_id)
|
|
|
|
if user.pop("stream_email_notify", False):
|
|
|
|
modern_event["stream_email_user_ids"].append(user_id)
|
|
|
|
if user.pop("wildcard_mention_notify", False):
|
2023-06-03 16:51:38 +02:00
|
|
|
modern_event["stream_wildcard_mention_user_ids"].append(user_id)
|
2021-06-18 19:30:57 +02:00
|
|
|
if user.pop("sender_is_muted", False):
|
|
|
|
modern_event["muted_sender_user_ids"].append(user_id)
|
|
|
|
|
|
|
|
# TODO/compatibility: Another translation code block for the rename of
|
|
|
|
# `always_push_notify` to `online_push_enabled`. Remove this
|
|
|
|
# when one can no longer directly upgrade from 4.x to 5.0-dev.
|
|
|
|
if user.pop("online_push_enabled", False) or user.pop("always_push_notify", False):
|
|
|
|
modern_event["online_push_user_ids"].append(user_id)
|
|
|
|
|
|
|
|
# We can calculate `mentioned` from the usermessage flags, so just remove it
|
|
|
|
user.pop("mentioned", False)
|
|
|
|
|
|
|
|
return (modern_event, user_dicts)
|
|
|
|
|
|
|
|
|
2024-09-12 11:46:48 +02:00
|
|
|
def process_user_group_name_update_event(event: Mapping[str, Any], users: Iterable[int]) -> None:
|
|
|
|
user_group_event = dict(event)
|
|
|
|
# 'deactivated' field is no longer needed and can be popped, as we now
|
|
|
|
# know whether the group that was renamed is deactivated or not and can
|
|
|
|
# avoid sending the event to client with 'include_deactivated_groups'
|
|
|
|
# client capability set to false.
|
|
|
|
event_for_deactivated_group = user_group_event.pop("deactivated", False)
|
|
|
|
for user_profile_id in users:
|
|
|
|
for client in get_client_descriptors_for_user(user_profile_id):
|
|
|
|
if client.accepts_event(user_group_event):
|
|
|
|
if event_for_deactivated_group and not client.include_deactivated_groups:
|
|
|
|
continue
|
|
|
|
client.add_event(user_group_event)
|
|
|
|
|
|
|
|
|
2017-11-27 11:09:23 +01:00
|
|
|
def process_notification(notice: Mapping[str, Any]) -> None:
|
2021-02-12 08:20:45 +01:00
|
|
|
event: Mapping[str, Any] = notice["event"]
|
2024-07-12 02:30:23 +02:00
|
|
|
users: list[int] | list[Mapping[str, Any]] = notice["users"]
|
2024-02-07 21:52:17 +01:00
|
|
|
start_time = time.perf_counter()
|
2020-02-03 17:09:18 +01:00
|
|
|
|
2021-02-12 08:20:45 +01:00
|
|
|
if event["type"] == "message":
|
2021-06-18 19:30:57 +02:00
|
|
|
if len(users) > 0 and isinstance(users[0], dict) and "stream_push_notify" in users[0]:
|
|
|
|
# TODO/compatibility: Remove this whole block once one can no
|
|
|
|
# longer directly upgrade directly from 4.x to 5.0-dev.
|
|
|
|
modern_event, user_dicts = reformat_legacy_send_message_event(event, users)
|
|
|
|
process_message_event(modern_event, user_dicts)
|
|
|
|
else:
|
2024-07-12 02:30:17 +02:00
|
|
|
process_message_event(event, cast(list[Mapping[str, Any]], users))
|
2021-02-12 08:20:45 +01:00
|
|
|
elif event["type"] == "update_message":
|
2024-07-12 02:30:17 +02:00
|
|
|
process_message_update_event(event, cast(list[Mapping[str, Any]], users))
|
2021-02-12 08:20:45 +01:00
|
|
|
elif event["type"] == "delete_message":
|
2024-09-10 20:02:28 +02:00
|
|
|
process_deletion_event(event, cast(list[int], users))
|
2021-02-12 08:20:45 +01:00
|
|
|
elif event["type"] == "presence":
|
2024-07-12 02:30:17 +02:00
|
|
|
process_presence_event(event, cast(list[int], users))
|
2022-10-27 19:05:10 +02:00
|
|
|
elif event["type"] == "custom_profile_fields":
|
2024-07-12 02:30:17 +02:00
|
|
|
process_custom_profile_fields_event(event, cast(list[int], users))
|
2023-10-24 19:47:39 +02:00
|
|
|
elif event["type"] == "realm_user" and event["op"] == "add":
|
2024-07-12 02:30:17 +02:00
|
|
|
process_realm_user_add_event(event, cast(list[int], users))
|
2024-09-12 11:46:48 +02:00
|
|
|
elif event["type"] == "user_group" and event["op"] == "update" and "name" in event["data"]:
|
|
|
|
# Only name can be changed for deactivated groups, so we handle the
|
|
|
|
# event sent for updating name separately for clients with different
|
|
|
|
# capabilities.
|
|
|
|
process_user_group_name_update_event(event, cast(list[int], users))
|
2022-09-22 22:09:34 +02:00
|
|
|
elif event["type"] == "cleanup_queue":
|
|
|
|
# cleanup_event_queue may generate this event to forward cleanup
|
|
|
|
# requests to the right shard.
|
|
|
|
assert isinstance(users[0], int)
|
|
|
|
try:
|
|
|
|
client = access_client_descriptor(users[0], event["queue_id"])
|
|
|
|
except BadEventQueueIdError:
|
|
|
|
logging.info(
|
|
|
|
"Ignoring cleanup request for bad queue id %s (%d)", event["queue_id"], users[0]
|
|
|
|
)
|
|
|
|
else:
|
|
|
|
client.cleanup()
|
2014-04-24 02:16:53 +02:00
|
|
|
else:
|
2024-07-12 02:30:17 +02:00
|
|
|
process_event(event, cast(list[int], users))
|
2020-05-02 08:44:14 +02:00
|
|
|
logging.debug(
|
|
|
|
"Tornado: Event %s for %s users took %sms",
|
2021-02-12 08:20:45 +01:00
|
|
|
event["type"],
|
2021-02-12 08:19:30 +01:00
|
|
|
len(users),
|
2024-02-07 21:52:17 +01:00
|
|
|
int(1000 * (time.perf_counter() - start_time)),
|
2020-05-02 08:44:14 +02:00
|
|
|
)
|
2014-04-24 02:16:53 +02:00
|
|
|
|
2021-02-12 08:19:30 +01:00
|
|
|
|
2024-07-12 02:30:17 +02:00
|
|
|
def get_wrapped_process_notification(queue_name: str) -> Callable[[list[dict[str, Any]]], None]:
|
|
|
|
def failure_processor(notice: dict[str, Any]) -> None:
|
2020-04-09 18:31:04 +02:00
|
|
|
logging.error(
|
2020-05-02 08:44:14 +02:00
|
|
|
"Maximum retries exceeded for Tornado notice:%s\nStack trace:\n%s\n",
|
2021-02-12 08:19:30 +01:00
|
|
|
notice,
|
|
|
|
traceback.format_exc(),
|
|
|
|
)
|
2020-04-09 18:31:04 +02:00
|
|
|
|
2024-07-12 02:30:17 +02:00
|
|
|
def wrapped_process_notification(notices: list[dict[str, Any]]) -> None:
|
2020-10-10 05:24:35 +02:00
|
|
|
for notice in notices:
|
|
|
|
try:
|
|
|
|
process_notification(notice)
|
|
|
|
except Exception:
|
|
|
|
retry_event(queue_name, notice, failure_processor)
|
2020-04-09 18:31:04 +02:00
|
|
|
|
|
|
|
return wrapped_process_notification
|