mirror of
https://mau.dev/maunium/synapse.git
synced 2024-10-01 01:36:05 -04:00
2292dc35fc
This is a potential solution to https://github.com/vector-im/riot-web/issues/3374 and https://github.com/vector-im/riot-web/issues/5953 as raised by Mozilla at https://github.com/vector-im/riot-web/issues/10868. This lets you define a push rule action which increases the badge count (unread notification) count on a given room, but doesn't actually send a push for that notification via email or HTTP. We might want to define this as the default behaviour for group chats in future to solve https://github.com/vector-im/riot-web/issues/3268 at last. This is implemented as a string action rather than a tweak because: * Other pushers don't care about the tweak, given they won't ever get pushed * The DB can store the tweak more efficiently using the existing `notify` table. * It avoids breaking the default_notif/highlight_action optimisations. Clients which generate their own notifs (e.g. desktop notifs from Riot/Web would need to be aware of the new push action) to uphold it. An alternative way to do this would be to maintain a `msg_count` alongside `highlight_count` and `notification_count` in `unread_notifications` in sync responses. However, doing this by counting the rows in `events` since the `stream_position` of the user's last read receipt turns out to be painfully slow (~200ms), perhaps due to the size of the events table. So instead, we use the highly optimised existing event_push_actions (and event_push_actions_staging) table to maintain the counts - using the code paths which already exist for tracking unread notification counts efficiently. These queries are typically ~3ms or so. The biggest issues I see here are: * We're slightly repurposing the `notif` field on `event_push_actions` to track whether a given action actually sent a `push` or not. This doesn't seem unreasonable, but it's slightly naughty given that previously the field explicitly tracked whether `notify` was true for the action (and as a result, it was uselessly always set to 1 in the DB). * We're going to put more load on the `event_push_actions` table for all the random group chats which people had previously muted. In practice i don't think there are many of these though. * There isn't an MSC for this yet (although this comment could become one). |
||
|---|---|---|
| .. | ||
| engines | ||
| schema | ||
| util | ||
| __init__.py | ||
| _base.py | ||
| account_data.py | ||
| appservice.py | ||
| background_updates.py | ||
| client_ips.py | ||
| deviceinbox.py | ||
| devices.py | ||
| directory.py | ||
| e2e_room_keys.py | ||
| end_to_end_keys.py | ||
| event_federation.py | ||
| event_push_actions.py | ||
| events_bg_updates.py | ||
| events_worker.py | ||
| events.py | ||
| filtering.py | ||
| group_server.py | ||
| keys.py | ||
| media_repository.py | ||
| monthly_active_users.py | ||
| openid.py | ||
| prepare_database.py | ||
| presence.py | ||
| profile.py | ||
| push_rule.py | ||
| pusher.py | ||
| receipts.py | ||
| registration.py | ||
| rejections.py | ||
| relations.py | ||
| room.py | ||
| roommember.py | ||
| search.py | ||
| signatures.py | ||
| state_deltas.py | ||
| state.py | ||
| stats.py | ||
| stream.py | ||
| tags.py | ||
| transactions.py | ||
| user_directory.py | ||
| user_erasure_store.py | ||