Change #927619 abandoned by D3r1ck01:

[mediawiki/extensions/Flow@master] [WIP] Fix failing tests due to Parsoid being enabled & used (by default)

Reason:

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

Questions from @Bmueller:

• What are the dependencies (code, and/or people)?
  • "Categories" are a fairly small feature. It builds on general platform concepts like JobQueue, DeferredUpdates, and utility functions, but I don't think this task requires changes to other components or feature behaviours. As such, while not exactly standalone, I'd say it has no code dependencies that we need to be mindful of in this context. In terms of teams, the feature is unowned. The task does not require making behaviour changes besides obvious bug fixes, so no controversial decisions or indirect product impact expected there.
• What is the impact of this?
  • Sustainability: the current implementation is needlessly complex and redundant and yet still seeems to regularly produce inaccurate counts. It is prune to production errors and load problems. e.g. T352628: Fatal exception of type "Wikimedia\Rdbms\DBTransactionSizeError", per @Ladsgroup above.
  • Product experience: The most prominent use category counts, where the number itself is imporant/sensitive, is Wikipedia maintenance categories, and similar "meta" categories on other wikis. The counts are often used to power templates, gadgets, and bots to know when a particular kind of issue has more than 0 articles affecting it. The problem is often that the category will either be zero when it shouldn't be or above zero when it should be zero. To clarify: The problem is not e.g. when a category containing 100+ items and the number being off by a few, which would not be a big problem in that case. We have ~15 duplicate bug reports about this at the moment, dating back several years.
• What would it cost to fix? TBD.

In T221795#9666191, @Ladsgroup wrote:

FWIW, this system has caused an incident where several million articles were not editable because this process locked 3M rows in pagelinks. Fixing that would improve our resilience.

FWIW, this system has caused an incident where several million articles were not editable because this process locked 3M rows in pagelinks. Fixing that would improve our resilience.

@daniel: Per emails from Sep18 and Oct20 and https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup , I am resetting the assignee of this task because there has not been progress lately (please correct me if I am wrong!). Resetting the assignee avoids the impression that somebody is already working on this task. It also allows others to potentially work towards fixing this task. Please claim this task again when you plan to work on it (via Add Action... → Assign / Claim in the dropdown menu) - it would be welcome. Thanks for your understanding!

Change 777483 abandoned by Krinkle:

[mediawiki/core@master] [WIP] HookRunner: Implement a fast HookRunner for load.php

Reason:

No significant redunction left after the PSR-4 classmap change.

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

Change 954630 merged by jenkins-bot:

[mediawiki/core@REL1_39] Include core PSR-4 classes in the generated classmap

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

Change 954630 had a related patch set uploaded (by Reedy; author: TK-999):

[mediawiki/core@REL1_39] Include core PSR-4 classes in the generated classmap

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

Change 936659 merged by jenkins-bot:

[mediawiki/core@master] virtualrest: Hard deprecate VirtualRESTService & VirtualRESTServiceClient

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

Change 936659 had a related patch set uploaded (by D3r1ck01; author: Derick Alangi):

[mediawiki/core@master] virtualrest: Hard deprecate VirtualRESTService

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