In T213478#5517007, @Daimona wrote:

Yes, it wouldn't perform really well. OTOH, the maintenance script has:

SELECT rev_text_id FROM revision

and

SELECT ar_text_id FROM archive

which are equally, if not more expensive.

In T213478#5516417, @Daimona wrote:

But well, reading it again... Would it be enough to just add a hook as proposed above? Something like 'PurgeRedundantText', and extensions may provide a list of IDs to spare. For, AF, it would be something along the lines of:

In T228675#5516794, @Pchelolo wrote:

All of the above are addressed by the existing patches.

Bumping back to inbox, since this got tagged for the 1.34 release, which makes it urgent.

I just realized that SpecialReplaceText has a direct reference to old_text. That needs to be fixed as well.

In T222099#5507901, @Reedy wrote:

So, yeah, it's Kask (even if indirectly), and the way MW uses it is breaking this behaviour. It worked not using Kask. So the next question is does this just break OATHAuth? Or do other extensions put objects in and therefore will expect it to work?

In T232485#5507100, @eprodromou wrote:

@Krinkle @daniel So, I guess this is an RFC now? What do I need to do next?

In T232485#5507155, @eprodromou wrote:

Discussing this proposal on Tuesday with Tim, he strongly objected to having the word "core" in the prefix, since none of the other APIs referenced above have the word "core" in them. So, I've removed the "core" from the proposal.

This RFC has entered the Last Call period per the TechCom meeting on September 18. The last call will end on October 2nd. If no issues remain unaddressed by that time, this RFC will be approved as proposed.

Moved by to TechCom inbox. I have updated the task description to reflect the current state of the proposal. The draft for the stable interface policy can be found at https://www.mediawiki.org/wiki/Stable_Interface_Policy. If there are no objections, I think the draft can go on Last Call next week. Please put any comments or questions here rather than the talk page on the wiki. I'm more likely to see them here, and they are in context of the prior discussion.

In T193613#5505604, @dcausse wrote:

Just in case it helps the discussion: here is a list of all the PHP interfaces declared in core and how they are implemented in extensions. In the end there are very few and even fewer are the ones that could not be transformed to an abstract base class. I did not analyze inter-extension dependencies.

Putting this in the RFC inbox for discussion.

Proposal needs an update, I plan to do this next week.

Untagging TechCom, since this has been decoupled from the text table and content table.

In T230862#5503781, @Cparle wrote:

So say we add a 'structured-data-mediainfo' tag to every revision that has a mediainfo slot - would that be adequate? @EBernhardson ?

In T224949#5503324, @CCicalese_WMF wrote:

Could this error be related?
https://lists.wikimedia.org/pipermail/wikitech-l/2019-September/092551.html

In T231930#5499695, @Anomie wrote:

In T231930#5498357, @daniel wrote:

I think ActingUser comes in two flavors, which could be subclasses or distinguished by asking the object: 1) a user acting via a web request. Additional restrictions may applies. 2) a user user acting without a web request, so no additional restrictions apply.

Then what exactly is the difference between your "ActingUser2" and a normal UserIdentity? Just some semantics with no actual code difference?

The link cache is for the title -> id lookup. Seems to me like you need the opposite here. The batch interface would be Title::newFromIDs (note the plural), but that does no caching.

In T214308#5499106, @Lucas_Werkmeister_WMDE wrote:

Why is this tagged Wikidata? Is Wikibase incompatible with the new schema or something? (It looks like production is currently configured to write both but read new – perhaps Wikibase still reads old somewhere?)

In T233092#5498618, @mobrovac wrote:

What about using the RunSingleJob.php RPC end point that is used in production? It doesn't require a special token and since it's the way it's done in production, it brings CI tests closer to a more realistic set-up.

In T231930#5466782, @Tgr wrote:

I think all code that does "secure" permission checks should require that an ActingUser is given.

One implication there is that system users would have to be ActingUser since they do perform actions which trigger secure permission checks, even though they don't have associated IPs or requests. So ActingUser (with the interface envisioned in the task description) doesn't seem like a natural abstraction.

In T18691#5495817, @alexhollender wrote:

Yes, we are planning on enabling the feature on en.wiki once it becomes available.

T196575: Add block cookie for browser-based API edits (including VisualEditor & MobileFrontend) seems to indicate that we need to be able to manipulate the response (cookies) from the context of block management as well.

In T196575#5495565, @Tchanders wrote:

In T196575#5472917, @Krinkle wrote:

Calling trackBlockWithCookie() as standard part of pre-shutdown on web requests will:

• [...] Let getUserBlock remain predictable (no side-effect), and keep BlockManager separate from implicitly depending on WebResponse or otherwise making it unsafe to use post-send or outside web requests.

getUserBlock can still have the side-effect of clearing the block cookie. Have suggested a fix in: https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/537099/

In T224949#5489415, @MarkAHershberger wrote:

fixed by adding a row with role_id=2 and role_name='aux'

@osorio-juan-microsoft Thanks, that does sound like it would be difficult to do this in an extension. And if we (WMF) don't enable it, it probably wouldn't need an RFC. But if we are planning to enable it on WMF sites, it will need a closer look.

In T18691#5488601, @Msftwikipmey wrote:

#2 - Does "deployment on WMF systems" mean to make this part of MediaWiki core software? I think this has always been the expectation, which is why it has gone through many iterations of design, i18n and perf improvement :) Could WMF friends chime in to confirm this is still the case?

In T18691#5488413, @CCicalese_WMF wrote:

It seems that the design questions are resolved and the implementation is under review. Should the RFC be scheduled for discussion at TechCom?