Page MenuHomePhabricator

Stop sending change notification email if edit is done by a bot
Closed, ResolvedPublic

Description

Bots do a lot of edits and it can easily drown the notified person.

We already hide bot edits from default view and users always can check their watchlist to catch up on what was missed.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Change 997861 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):

[mediawiki/core@master] mail: Stop sending notification email if edit is done by a bot

https://gerrit.wikimedia.org/r/997861

Hello @Ladsgroup! For Tech News, what wording would you suggest as the content, and When should it be included? Thanks!"

Hi, something along the lines of:

If you have "Email me when a page or a file on my watchlist is changed " option enabled, bot edits will no longer trigger notification emails. You can still see bot edits in [[Special:Watchlist]].

It should be included ASAP. We are planning to deploy this really soon.

@Ladsgroup there is a comment in the Tech News: 2024-07 talk page concerning this change after I added it to the Tech News:

Hi. It's a new bug? When it will be fixed? It could be potentially a good thing, but only after the problem of changing the behavior to "wait until the first non-bot edit and then trigger notification" instead of current "do not notify never if there was at least one bot edit, causing users not to be aware of any edits, bot or non-bot" will be fixed after so many years.

Please can someone reply to this comment or add the response here for me to reply? Thank you!

I responded there, I also added a link to this ticket in tech news.

Change 997861 merged by jenkins-bot:

[mediawiki/core@master] mail: Stop sending notification email if edit is done by a bot

https://gerrit.wikimedia.org/r/997861

Ladsgroup claimed this task.

Change 998983 had a related patch set uploaded (by Tacsipacsi; author: Tacsipacsi):

[mediawiki/core@master] Revert "mail: Stop sending notification email if edit is done by a bot"

https://gerrit.wikimedia.org/r/998983

Tacsipacsi triaged this task as Unbreak Now! priority.

The revert should be merged before it hits production and edits by bot accounts start (irreversibly) being handled as seen.

Ladsgroup lowered the priority of this task from Unbreak Now! to Medium.Mon, Feb 12, 8:56 AM

If you disagree with a change, it doesn't mean it has to be reverted.

Tacsipacsi raised the priority of this task from Medium to Unbreak Now!.Mon, Feb 12, 9:01 AM

This is BROKEN and causes DATA LOSS. I can work with you on a better solution, but not if you’re not willing to accept that it’s not just my personal taste, but you got it wrong. And I’m not the only one who thinks it’s unacceptable.

It doesn't lead to data loss...

Then how do you call the fact that the database write necessary to highlight the bot edit in the watchlist doesn’t happen?

If that's data loss, we are having data loss since T29884

No, because bot edits used to be correctly highlighted on Special:Watchlist before your patch. The data was there, it just wasn’t delivered in one particular way. Now, it’s not persisted and thus not accessible in any way.

Change 1002391 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):

[mediawiki/core@master] mail: Still update the notification timestamp for bot edits

https://gerrit.wikimedia.org/r/1002391

Joe lowered the priority of this task from Unbreak Now! to Medium.Mon, Feb 12, 9:55 AM
Joe added a subscriber: Joe.

@Tacsipacsi I would ask you to keep emotions in check, it's very hard to collaborate (which is what we are supposed to be doing here) when someone is that confrontational. Specifically:

  • yelling doesn't get your point through better, quite the opposite. In fact, took me quite a bit to understand what you were trying to say.
  • raising tasks to UBN! because you're in disagreement also won't get your point through better,.

Let me also add, not making this change has serious potential operational consequences. So the change of preventing sending emails on bot edits needs to happen.

As I understand it, this change would prevent sending emails on bot edits, but also avoid bolding the item because the bolding happens in the email sending job. We can improve the change to make the UX better for editors, but this is not a data loss, nor an unbreak now! issue.

On the other hand, if we don't make this change, we'll have potentially situations where emails will not get delivered, and not just for bot edits, for anything from login recovery to user-to-user emails to watchlist notifications (of any nature).

I've asked to retrieve my bot flag, which I temporarily gave away a while ago due to lack of time. I know pretty well what is going on now on Watchlist in different modes, because I wrote a huge gadget, Whatchlist Manager, years ago. So, I'm planning to create various use cases to check what is the state after the deployment. Starting from this one:

  1. Open some watched page at 23:59.
  2. Close it.
  3. Go away for an hour.
  4. During this period, another accounts edit this page: three non-bot edits, a bot edit, three more non bot edits.
  5. Return to the screen and open the Watchlist in group mode, showing new edits only.

I expect to see a new group with seven edits. As far as I understand from todays Tech News, I will see none. Those before because of the new change, since marking an edit as seen marks automatically all the previous ones. Those after because of the mentioned old bug in the new conditions. The best result will be if I see all the seven.

I don't think what you're describing will happen. Will try it after deploy and let us know.

Change 1002391 merged by jenkins-bot:

[mediawiki/core@master] mail: Still update the notification timestamp for bot edits

https://gerrit.wikimedia.org/r/1002391

Change 998983 abandoned by Tacsipacsi:

[mediawiki/core@master] Revert "mail: Stop sending notification email if edit is done by a bot"

Reason:

In favor of I7f1b6f2adcbb22703f52d7ac0e4322379f81ebdc

https://gerrit.wikimedia.org/r/998983

I call this resolved. Let me know if you have any concerns. I continue to work on improvements.

@Tacsipacsi I would ask you to keep emotions in check

I tried to, but it’s very upsetting that I try to prevent a very bad commit (although done in good faith) from hitting production, and all I get is comments and −2’s that say that it’s wrong, or comments that designate my arguments as “disagreement”.

Let me also add, not making this change has serious potential operational consequences. So the change of preventing sending emails on bot edits needs to happen.

What are those serious operational consequences? What is too high? The number of jobs? The database size? The mail traffic? Please note that the two changes (9dc68fb, f40a495) only marginally affected the number of outgoing mails, as most bot edits already generated no mail due to the condition

!$minorEdit || ( $config->get( MainConfigNames::EnotifMinorEdits ) && !$editor->isAllowed( 'nominornewtalk' ) )

i.e. users with nominornewtalk right (this includes bots) don’t send notification mails on minor edits – and most bot edits are minor.

@Ladsgroup also wrote on Gerrit that “There are lots of reasons to make this change. I can provide you those reasons privately.” Why can’t those reasons be stated publicly?

As I understand it, this change would prevent sending emails on bot edits, but also avoid bolding the item because the bolding happens in the email sending job. We can improve the change to make the UX better for editors, but this is not a data loss

If the data necessary for bolding those lines isn’t written to the database, then it hasn’t been written, and the information for that time range is lost.

On the other hand, if we don't make this change, we'll have potentially situations where emails will not get delivered, and not just for bot edits, for anything from login recovery to user-to-user emails to watchlist notifications (of any nature).

Again, without any public details, I don’t know how big the risk is. What I know is that watchlist notifications not being delivered is not only potential, but a real thing (T29884, T40874), and has been for ages. This means two things:

  • This should be handled in some way, hopefully sooner rather than later.
  • Editors are used to this issue, probably have developed workarounds (e.g. check Special:Watchlist regularly): that “sooner rather than later” doesn’t mean ASAP, there’s no rush.

So when I realized the new bug on Saturday, i.e. one workday before the train branch cut, I felt that the priority and the realistically possible thing is reverting now and fixing later. Now that it has been (largely) reverted, I’m happy to work together on a solution that satisfies all parties: operators, users wanting to be notified about bot edits and users not wanting to miss emails about non-bot edits.

Well, I've just tried four most significant scenarios, and it works fine.

@UOzurumba Hi, this was already announced in the last tech news, why announcing it again?

Well, I've just tried four most significant scenarios, and it works fine.

Tried the rest, they are ok too.

@UOzurumba Hi, this was already announced in the last tech news, why announcing it again?

It wasn't: https://meta.wikimedia.org/wiki/Tech/News/2024/07.

Since the train arrived, I’ve missed

All this because of obscure reasons like “serious potential operational consequences”.

All this because of obscure reasons like “serious potential operational consequences”.

"Why can’t those reasons be stated publicly?" this essentially always means it is a security sensitive topic and disclosing it publicly could have impact. While I realise that it is annoying that you are not privy to all details, that is exactly how it should be. The fact that this has to be spelled out to a very seasoned editor and regular code contributor, drawing more attention to the problem is honestly kinda problematic.

"Why can’t those reasons be stated publicly?" this essentially always means it is a security sensitive topic and disclosing it publicly could have impact.

Or that the people who are in the know don’t take time to determine exactly what details are sensitive and disclose parts that aren’t.

While I realise that it is annoying that you are not privy to all details, that is exactly how it should be.

It’s not just the details, it’s at least a rough understanding of the problem. And it’s not just annoying, it makes it impossible to work together on a solution that helps with this problem without making the wikis less usable. For example, if the problem is the amount of outbound mail traffic, my proposal that tries to reduce the number of unnecessarily scheduled jobs won’t help. If the problem is the amount of jobs, optimizing DB queries won’t help. I’ve spent a bit of time over the weekend understanding how the code works, and I have several ideas for improvement (mail traffic, job count, response time, database query optimization), but these are often contradicting, and I can’t propose solutions if I don’t know what the problem is. I can keep uploading patches that try restore the previous status quo, but that won’t really bring us forward.

The issue I've had is that, whenever a bot edits a page or file, I don't receive any notification emails for that page or file from that point forward, which includes any subsequent edits by humans.

Good god. First we can't fix T250856, and now we're making the problem worse??? I might be in the minority of wanting to get every edit made to my watchlist to my inbox, but I feel like this goes over the top to fix what is not necessarily an issue.

Please tell me I'm missing something here.