Putting this into the PET icebox. This doesn't mean it shouldn't be done (I'm very much in favor), it just means that it's unlikely to get on PET's roadmap in the foreseeable future.

In T272081#6753627, @Krinkle wrote:

The EditPage issue seems a rather unusual exception to that, one that I think is a clear signal that it is doing something fragile that we should interpret as a nudge to find a better approach, not solidify it further by hiding the anti-pattern behind a built-in method.

Approved after last call per Wednesday's TechCom meeting.

In T28741#6750848, @jcrespo wrote:

My worry would be for commonswiki (and possibly enwiki) going back to having problems of scaling due to inserting + scanning lots of rows on revision (or more technically, increasing the current ones). Thanks to your work, and others, we "stopped the fires" of the revision table, but we didn't win the war :-D.

In T28741#6749820, @Tgr wrote:

@daniel how would you imagine the end stage of the MCR migration? Put what's currently an image table row into a JSON object and store it as content on some non-main slot?

In T28741#6746635, @Tgr wrote:

I imagine the first step for MCR would be to create a slot which just contains a filerevision ID. Completely merging filerevision into revision would be a lot more work which should definitely be attempted in a single step; and I'm not sure we have compelling reasons for doing it at all. So this task is a step towards MCR images.

Moving this to "feature request review". The question is mainly under what conditions we want to remove watchlist entries. While the motivation is technical (free up capacity), the question of criteria is not. We can't engineer a solution if we don't know the requirements.

Should we work together with Structured Data Engineering on this, as a knowledge transfer opportunity? They own image scaling at least in theory, right?

I'm happy to pair with Platform Team Workboards (Clinic Duty Team) folks to finish and review the patch https://gerrit.wikimedia.org/r/655037

Since this doesn't appear to be happening on WMF sites, it's unclear what the priority of this ticket should be.

In T190178#6739785, @holger.knust wrote:

Is this resolved?

Triggered by requesting page info of non-existing pages. Should be fixed by the patch I just uploaded.

Triggered by requesting page info of non-existing pages. Should be fixed by the patch I just uploaded.

In T271804#6739408, @RhinosF1 wrote:

Looking at the code, it's probably https://github.com/wikimedia/mediawiki/commit/21d6f1cd6a0504089c5a13c2be0620c9cde45afd#diff-048e872833a49129ace85eee8a5dd6d21e5c0f5948265e634a5d0c9d242f9110L504 ??

In T222224#6737148, @Ladsgroup wrote:

I just want to say that with the recent changes with revision table (MCR work). Now the biggest table of enwiki is pagelinks not revision table.

Sounds like a good plan!

Note that we are about to go full circle pn User::isAllowed with T231930