Page MenuHomePhabricator

Investigate maximum echo notification count
Closed, ResolvedPublic

Description

There is a limit of 2000 notifications. We should first double-check we actually still need such a limit (it says, "What we gain from this is we could run expensive queries otherwise that would requires adding index and data denormalization.." but that comment could be stale).

If we do, @Mooeypoo suggested splitting the count. E.g. 1000 each of alerts and messages (or 500 alerts, 1500 messages), so a flood of alerts can't clobber your (more important) messages.

Event Timeline

Mattflaschen-WMF raised the priority of this task from to Needs Triage.
Mattflaschen-WMF updated the task description. (Show Details)
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

IMO we should consider making these time based rather than a raw count.

I actually think this is a bit more complicated than that, potentially.

I am not sure how much traffic there is on average, but consider a prolific user that is active on several wikis, concentrating effort mainly on maintenance/cleanup stuff that usually produce alerts.
She may get hundreds of notifications a week, but only dozens of messages a month. If she doesn't look at her messages for a certain amount of time -- or alternatively if there's a sudden spam attempt that fills her notification list with alerts -- she may one day wake up to see her entire message inbox empty.

Consider another scenario, in which the user has 10 messages and, say, 1800 alerts. 4 of those messages are unread, and the user keeps them unread until she decides she has the time to deal with them. And yet, once either time elapses (if we go with time based) or raw count surpasses X, those messages vanish.

Also, since the message popup only appears if there are messages in the queue, both of these scenarios not only will show an empty queue, they will make the message badge *vanish* completely. This can be quite confusing to users who used to have messages in there - especially unread ones, but in general as well.

Whatever we do, I suggest that we consider the following:

  • Separate the limit between messages and alerts, especially since the popups are now separated.
  • Always keep unread messages on the expense of read ones. If we need to "clean up" then we should purge unread messages and keep read ones, regardless of the timestamp. The only case where we should purge unread messages is if the total number of unread messages goes above some limit.
  • Separate the limit between messages and alerts, especially since the popups are now separated.

Agree. Also, if we agree messages are more important, this guarantees alerts will never clobber messages.

  • Always keep unread messages on the expense of read ones. If we need to "clean up" then we should purge unread messages and keep read ones, regardless of the timestamp. The only case where we should purge unread messages is if the total number of unread messages goes above some limit.

Makes sense.

I would also guess count-based makes more sense than time-based, DB performance-wise.

If so, we would only do time-based for product reasons, but I'm not sure we want do that for product reasons.

Catrope triaged this task as Medium priority.Sep 2 2015, 11:25 PM
Catrope subscribed.
Catrope claimed this task.
Catrope removed Catrope as the assignee of this task.