Hi @Ladsgroup . It's nice to meet you. Hope you don't mind the ping, am hoping for some DBA advice. Extension PageTriage currently writes two of the exact same log entry to two Special:Logs, and I am thinking about stopping this behavior. My question is, since one of the logs is just duplicate data, would DBAs be interested in deleting the data later, or should we leave it alone?

The logs are pagetriage-deletion/deletion and pagetriage-curation/deletion. The one I am thinking about stopping writing to is pagetriage-deletion/deletion. The code is here. I see the same duplication code in a commit from 2012, so I think PageTriage has behaved this way its entire life.

Thanks a lot. Looking forward to your feedback.

Please tag DBA for requested input from DBAs (as pinging individuals does not scale) - thanks a lot! :)

There is BTW a tag for asking question to the data persistence team, but for projects in which we are not involved directly- for asking feedback. I've added it here (but didn't remove the dba one, as it is up to the dbas to manage it).

The one thing I would ask back is about is the size of the deletion request- how many wikis and how many log entries (approximately- if you know it) will be deleted- if 5 or 5 million, the scope will change dramatically :-D. Being on the data recovery side of things I am interested on monitoring this, in case the deletion process goes badly. Also please be patient, cleanup tasks are not usually the highest priority, and the DBAs are super-busy. Thank you! 0:-)

Hey there. It'd be enwiki only. It'd be 102,000-ish rows in the logging table. Quarry link.

This task has no urgency. I'm just checking as a courtesy. I figure it'd be a small efficiency to delete 100k duplicate log entries.

Of course don't do it yet, I haven't even written the patch. But wanted to formulate a gameplan.

Change 815702 had a related patch set uploaded (by Novem Linguae; author: NovemLinguae):

[mediawiki/extensions/PageTriage@master] Remove "Deletion tag log" from Special:Log

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

Nice to meet you and thank you for caring about new page patrolling! It's highly appreciated.

I can take care of the deletion once the patch is approved/merged.

If the data is being deleted, it can probably be dropped from maintain-views too

How that's related in this case?

It's listed in https://gerrit.wikimedia.org/g/operations/puppet/+/30ce51de11310f9771c7240d519d850ce4864cc2/modules/profile/templates/wmcs/db/wikireplicas/maintain-views.yaml#210 which won't be needed if there's no matching records anymore.

I don't think deleting the log data is a good idea. What if someone linked to a specific log entry and it gets deleted? I think it is unfortunate that we have been double-logging up until now but we should just stop doing it and move on, leaving the existing duplication in place.

We have had cases of mass removal of log entries. e.g. five years ago we removed all auto patrol logs removing 1.1B rows. I did a similar thing for flaggedrevs auto-review logs which were tens of millions if not hundreds of millions of rows.

I'm not saying this means we should delete the rows but I'm saying we have precedent for such cases. We don't guarantee our logs stay there forever.

Change 815702 merged by jenkins-bot:

[mediawiki/extensions/PageTriage@master] Remove "Deletion tag log" from Special:Log

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

It is not obvious to editors not involved with page curation (ie most of them) that deletion marking is to be found in the page curation log rather than the deletion log. An easy way for users to get to the correct log should be provided by pointing them to it in the relevant places.

Happy to add. What are some examples of relevant places?

In the header of the deletion log special page for a start, since that's where it used to be logged and people will go if they've used that search before. Possibly also the header of Special:Logs, at least temporarily until people get used to the new system.

The deletion tag log is still appearing in the list of logs. Likely need another patch to hide this, then as discussed above we can ask a DBA to delete the log entries.

To recap: we did not move the deletion tag log to the page curation log. Rather, the PageTriage software has been writing duplicate log entries to both logs since the beginning. So the goal is to hide and delete an unneeded, duplicated log (the deletion tag log).

Do first:

• Ask DBA to delete deletion tag log. Sounds like they are onboard with this in the phab discussion above.

Do after:

• Patch PageTriage to hide deletion tag log
• Patch operations/puppet -> maintain-views.yaml to not clone non-existent log type. This patch is similar but adds instead of removes a log type.

Note that a warning about this deletion was added to https://en.wikipedia.org/wiki/MediaWiki:Alllogstext

Or if there isn't an appetite to delete the Deletion Tag Log, can we just hide it from the picker at Special:Log? Again, all data in the Deletion Tag Log is a 1:1 duplicate of items in the Page Curation Log subtype Delete, so we are not losing any data.

I may release a patch just for this, as it seems more likely to gain consensus and is a good incremental step.

Change 855483 had a related patch set uploaded (by Novem Linguae; author: Novem Linguae):

[mediawiki/extensions/PageTriage@master] hide Deletion Tag Log from Special:Log

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

@Novem_Linguae Why do you think it can't be deleted? If it's okay with the community, just create a ticket and we will get to it.

Change 855483 merged by jenkins-bot:

[mediawiki/extensions/PageTriage@master] Hide Deletion Tag Log from Special:Log

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