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

Implement unread counter (MSC2625) #7673

Merged
merged 30 commits into from
Jun 17, 2020
Merged

Implement unread counter (MSC2625) #7673

merged 30 commits into from
Jun 17, 2020

Conversation

babolivier
Copy link
Contributor

@babolivier babolivier commented Jun 10, 2020

Fixes #7667

Implements matrix-org/matrix-spec-proposals#2625

TODO: change the following tests to test that a mark_unread action increments correctly the unread count:

  • tests.storage.test_event_push_actions.EventPushActionsStoreTestCase.test_count_aggregation
  • tests.replication.slave.storage.test_events.SlavedEventStoreTestCase.test_push_actions_for_user

ara4n and others added 8 commits September 19, 2019 00:54
…ations

This is a potential solution to https://github.com/vector-im/riot-web/issues/3374
and element-hq/element-web#5953
as raised by Mozilla at element-hq/element-web#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).
@babolivier babolivier requested a review from a team June 12, 2020 10:29
Copy link
Member

@richvdh richvdh left a comment

Choose a reason for hiding this comment

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

looks like good progress, a few thoughts

changelog.d/7673.feature Outdated Show resolved Hide resolved
synapse/push/bulk_push_rule_evaluator.py Outdated Show resolved Hide resolved
synapse/storage/data_stores/main/event_push_actions.py Outdated Show resolved Hide resolved
synapse/storage/data_stores/main/event_push_actions.py Outdated Show resolved Hide resolved
synapse/storage/data_stores/main/event_push_actions.py Outdated Show resolved Hide resolved
synapse/storage/data_stores/main/event_push_actions.py Outdated Show resolved Hide resolved
synapse/storage/prepare_database.py Outdated Show resolved Hide resolved
Copy link
Member

@richvdh richvdh left a comment

Choose a reason for hiding this comment

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

generally looks good. a couple of nits.

synapse/storage/data_stores/main/event_push_actions.py Outdated Show resolved Hide resolved
synapse/storage/data_stores/main/event_push_actions.py Outdated Show resolved Hide resolved
synapse/storage/data_stores/main/event_push_actions.py Outdated Show resolved Hide resolved
@babolivier babolivier requested a review from richvdh June 15, 2020 09:00
Copy link
Member

@richvdh richvdh left a comment

Choose a reason for hiding this comment

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

lgtm!

(though there is a conflict to resolve)

It might be nice to update sytest to check the new behaviour.

@babolivier
Copy link
Contributor Author

I've resolved the conflict, I'm looking into adding support in Sytest.

@babolivier
Copy link
Contributor Author

Sytest PR: matrix-org/sytest#890

@babolivier babolivier merged commit 46613aa into develop Jun 17, 2020
@babolivier babolivier deleted the babolivier/mark_unread branch June 17, 2020 09:58
babolivier added a commit to matrix-org/sytest that referenced this pull request Jun 17, 2020
Test for matrix-org/synapse#7673

This is basically hacking `Messages that notify from another user increment unread notification count` so it also runs for the action specified in MSC2625.
babolivier added a commit that referenced this pull request Jun 23, 2020
This reverts commit 46613aa, reversing
changes made to e452973.
@richvdh
Copy link
Member

richvdh commented Apr 5, 2022

for reference: this got backed out by #7761 and re-done in #7736, which was later backed out in #8039 and re-done yet again in #8059.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Implement unread counts (MSC2625)
4 participants