Well this certainly looks interesting....

As a guess I would say this has something todo with the ProofRead extension

So, I have spent a while now trying to reproduce this with the ProofRead extension installed (and the exact pages from da.wikisource but I have not managed to :/

Any ideas others may have would be greatly appreciated!

If we have somewhere I can poke with wikisource-bot, I can clumsily use touch.py on it

That may also be completely unrelated to Extension:ProofRead, since it also happened on Commons (see this comment).

Hmmm, well if it was just to do with the ProofRead thing I would say it was something to do with the pages not actually containing the category, and instead it being added in PageContent:: getParserOutput which calls $parserOutput->addCategory.

Looking into the commons thing now

The relevant piece of code in the ProofreadPage extension is https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FProofreadPage.git/9dca91b8d53c51a347205e2730cc4ff6f40b6811/includes%2Fpage%2FPageContent.php#L233

And the CommonsMetadata extension also does something similar in HookHandler.php in the onContentAlterParserOutput method with $parserOutput->addTrackingCategory

Still digging to see if this is event he cause, unable to reproduce manually still, now to try with pywikibot for the wikisource case (although pywikibot was no where near the commons case afaik)...

Right, well after spending a large proportion of my day trying to reproduce this (and failing) I think the way to move forward here would be to not worry about this in the initial patch for the feature.
As a precaution we can disable the feature on all wikisource wikis and all commons wikis (which is the only place that this has happened), and once merged we could perhaps debug further on beta and test.
I am still convinced this has something to do with the CommonsMetadata or ProofreadPage extension and the addCategory method in ParserOutput, but I am no closer to working out exactly why.
It is of course quite hard to look into this as all of the recent change entries that this task is refering to no longer exist in the DB.

If anyone else fancies looking at this please do! but @kai.nissen and myself are stumped! (for now) :)

That approach works for me. It is not a very common task that we need to undertake, so we can manage it as we go forward, and I will ensure that I back off the page touches or do it with batches with someone around. Thanks for the work that you have put in.

Change 235467 had a related patch set uploaded (by Addshore):
wgRCWatchCategoryMembership flase for commons & wikisource

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

Change 235467 abandoned by Addshore:
wgRCWatchCategoryMembership false for commons & wikisource

Reason:
currently disabled by default

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

Is this still a problem?

Have not been able to reproduce.

This feature is currently deployed on beta and will likely be slowly rolled out on projects soonish.

We could probably close this for now unless it re appears.

@Addshore just checking that you were working on something with the proofread page extension

This feature is due to be deployed on wikisource this Thursday again.
If we see similar things then we will revert the change and investigate.
(It will be much easier to investigate this time around as the changes will remain in the DB for us to look at)

Thursday? WSes usually get the deployment Tuesday. Is it being deployed out of session?

@Billinghurst the code deployment has happened already some time ago. What is missing is a config change to enable it on Wikisource (basically setting $wgRCWatchCategoryMembership) see https://gerrit.wikimedia.org/r/#/c/264735/. That can be done independently from software deployments.

Yep. Was just confirming. IRC didn't elicit a response. Thx.

This is now enabled on wikisource again!