|
12 | 12 | # See the License for the specific language governing permissions and |
13 | 13 | # limitations under the License. |
14 | 14 |
|
| 15 | +""" |
| 16 | +This module implements the push rules & notifications portion of the Matrix |
| 17 | +specification. |
| 18 | +
|
| 19 | +There's a few related features: |
| 20 | +
|
| 21 | +* Push notifications (i.e. email or outgoing requests to a Push Gateway). |
| 22 | +* Calculation of unread notifications (for /sync and /notifications). |
| 23 | +
|
| 24 | +When Synapse receives a new event (locally, via the Client-Server API, or via |
| 25 | +federation), the following occurs: |
| 26 | +
|
| 27 | +1. The push rules get evaluated to generate a set of per-user actions. |
| 28 | +2. The event is persisted into the database. |
| 29 | +3. (In the background) The notifier is notified about the new event. |
| 30 | +
|
| 31 | +The per-user actions are initially stored in the event_push_actions_staging table, |
| 32 | +before getting moved into the event_push_actions table when the event is persisted. |
| 33 | +The event_push_actions table is periodically summarised into the event_push_summary |
| 34 | +and event_push_summary_stream_ordering tables. |
| 35 | +
|
| 36 | +Since push actions block an event from being persisted the generation of push |
| 37 | +actions is performance sensitive. |
| 38 | +
|
| 39 | +The general interaction of the classes are: |
| 40 | +
|
| 41 | + +---------------------------------------------+ |
| 42 | + | FederationEventHandler/EventCreationHandler | |
| 43 | + +---------------------------------------------+ |
| 44 | + | |
| 45 | + v |
| 46 | + +-----------------+ |
| 47 | + | ActionGenerator | |
| 48 | + +-----------------+ |
| 49 | + | |
| 50 | + v |
| 51 | + +-----------------------+ +---------------------------+ |
| 52 | + | BulkPushRuleEvaluator |---->| PushRuleEvaluatorForEvent | |
| 53 | + +-----------------------+ +---------------------------+ |
| 54 | + | |
| 55 | + v |
| 56 | + +-----------------------------+ |
| 57 | + | EventPushActionsWorkerStore | |
| 58 | + +-----------------------------+ |
| 59 | +
|
| 60 | +The notifier notifies the pusher pool of the new event, which checks for affected |
| 61 | +users. Each user-configured pusher of the affected users then performs the |
| 62 | +previously calculated action. |
| 63 | +
|
| 64 | +The general interaction of the classes are: |
| 65 | +
|
| 66 | + +----------+ |
| 67 | + | Notifier | |
| 68 | + +----------+ |
| 69 | + | |
| 70 | + v |
| 71 | + +------------+ +--------------+ |
| 72 | + | PusherPool |---->| PusherConfig | |
| 73 | + +------------+ +--------------+ |
| 74 | + | |
| 75 | + | +---------------+ |
| 76 | + +<--->| PusherFactory | |
| 77 | + | +---------------+ |
| 78 | + v |
| 79 | + +------------------------+ +-----------------------------------------------+ |
| 80 | + | EmailPusher/HttpPusher |---->| EventPushActionsWorkerStore/PusherWorkerStore | |
| 81 | + +------------------------+ +-----------------------------------------------+ |
| 82 | + | |
| 83 | + v |
| 84 | + +-------------------------+ |
| 85 | + | Mailer/SimpleHttpClient | |
| 86 | + +-------------------------+ |
| 87 | +
|
| 88 | +The Pusher instance also calls out to various utilities for generating payloads |
| 89 | +(or email templates), but those interactions are not detailed in this diagram |
| 90 | +(and are specific to the type of pusher). |
| 91 | +
|
| 92 | +""" |
| 93 | + |
15 | 94 | import abc |
16 | 95 | from typing import TYPE_CHECKING, Any, Dict, Optional |
17 | 96 |
|
|
0 commit comments