Page MenuHomePhabricator

Avoid a massive wave of email notifications after the Bugzilla migration
Closed, ResolvedPublic

Description

Maybe this task is moot, but I'd rather ask in advance.

We are seeing the amount of email notifications that @flimport can create indirectly when assigning/CCing users on tasks based on the short active live that fab.wmflabs.org had. If we have exactly the same setup for the Bugzilla migration, we might end up spamming users with literally thousands of emails.

Is this assumption correct? If so, we'd better take measures.

The ideal solution would be that the actions of @flimport (and/or its Bugzilla and RT equivalents) would not generate notifications, but I'm not sure how simple would that be.

A simpler option would be to set in email preferences by default for everybody (or at least new users):

Ignore - A task's subscribers change.

This way we would save the biggest source of spam to new users, and everybody would be able to decide if/when to activate them. The noise created by the bot for "Assigned To" users is a lot smaller, and that information is more relevant in any case.

Event Timeline

Qgil created this task.Oct 7 2014, 11:36 AM
Qgil raised the priority of this task from to Needs Triage.
Qgil updated the task description. (Show Details)
Qgil added a project: Bugzilla-Migration.
Qgil changed Security from none to None.
Qgil added a subscriber: Qgil.
Qgil added a comment.Oct 8 2014, 11:56 AM

Related discussion at T572: Determine the fate of comment metadata from legacy systems in phabricator.wikimedia.org?

If we contact all the Bugzilla users to create accounts in Phabricator before the migration, and we get, say, plenty, then all the associations would be done while Phabricator is down, and then we could perhaps disable notifications for everybody, to save ourselves the big bunch.

As seen in wikimedia-devtools IRC:

<greg-g> twentyafterfour: quick question I thought of as I was falling asleep last night: we have the task changes going to the mailing list now, right? Will the import of BZ into prod Phab spam the list/irc with 70000 bugs and their changes? Just something to think about :)
<chasemp> we can take off the rule that adds wikibugs-l
<chasemp> all the magic is just a herald rule that says, if I fits I sits....but for adding wikibugs-l list to new issues

  • greg-g nods

<greg-g> please remember to disable it then :)
<greg-g> that's all

you accidentally a testing account! I did the same on accident last night :)

select count(userid) from profiles where date_sub(curdate(),INTERVAL 1 MONTH) <= last_seen_date;
871
select count(userid) from profiles where date_sub(curdate(),INTERVAL 1 YEAR) <= last_seen_date;
2606
<mutante> but this confuses me, even for "10 YEAR" i will get 2606
<andre__> according to https://bugzilla.mozilla.org/show_bug.cgi?id=240437 last_seen_date was only introduced in Bugzilla 4.4, and we upgraded to 4.4 in 02/2014

Hence number of users in last 12 months should be higher than 2606.

Qgil triaged this task as Normal priority.Oct 8 2014, 10:05 PM
Qgil assigned this task to chasemp.Oct 25 2014, 7:41 AM

https://bugzillapreview.wmflabs.org/ and the previous iterations didn't bring any wave of notifications. Marking as resolved.

Qgil closed this task as Resolved.Oct 25 2014, 7:42 AM
In T559#14965, @Qgil wrote:

https://bugzillapreview.wmflabs.org/ and the previous iterations didn't bring any wave of notifications. Marking as resolved.

For the records, that was only because mail wasn't set up on that test instance.
For the migration from Bugzilla to production Phab we actually ended up killing/flushing the queue at some point. :-/

Qgil added a comment.Dec 1 2014, 1:24 PM

Are you sure? All my memories of that weekend are blurred, :) but I remember discussing this task, and @chasemp replying that it was all fine.

In the migration from fab to phab, we would receive a bunch of emails every time a new user was imported and assigned/CCed to all their previous tasks. This is not happening now with newly imported users.

You two are talking about two different things :) The intention of this issue was indeed resolved. The mass of stuffs was in relation to internal processing...and the sheer mass of activity to even a small number of users.