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?

Quick summary from a conversation I had with Tim just now:

After some discussion, it seems to me that this is primarily about defining what we consider a stable interface. I thnk we should amend the deprecation policy to be explicit about this. Draft here:
https://www.mediawiki.org/wiki/User:DKinzler_(WMF)/Stable_Interface

In T221763#5483334, @hashar wrote:

One more I have noticed today:

enwiki

RevisionStoreRecord.php

The given Title does not belong to page ID 52943292 but actually belongs to 61713901

In T198492#5481746, @tstarling wrote:

No, it was never true. update.php has been used to drop fields since MW 1.5, 14 years ago, but there was no backlog of undropped fields at that time. update.php has always been the correct script in which to drop fields and tables.

In T232485#5480131, @Pchelolo wrote:

As I understand, we intend to bump versions for non-breaking changes. Having a minor version bump for any new field or new endpoint in the whole core, I could easily imagine API v1.100500 which makes the cache split problem more and more intimidating.

In T232485#5480088, @eprodromou wrote:

@daniel I meant that client developers will probably appreciate any drag on breaking changes. My guess is that we'll need to do it pretty often to begin with, but that breaking changes will get much more costly as we get more users on this API.

In T232485#5480039, @eprodromou wrote:

Client developers will probably think of that as a feature, not a bug! ;-)

In T232485#5479863, @Pchelolo wrote:

I don't see a problem here unless we remove a version. If we always return the latest minor version for the requested major version, and only make backwards-compatible changes (adding fields), we'd never bring an existing client by adding a new minor version.

In T232485#5479676, @Pchelolo wrote:

Exposing minor versions of the API in the path seems like a questionable solution. Changes between minor API versions should be backwards-compatible, so there's not real need for the client to request a specific non-latest version of the API.

In T229601#5469783, @Jdforrester-WMF wrote:

Hey there, should this be moved to 1.35? The cut is a couple of weeks away. If it needs to go out in 1.34, is there anything I can do to help get it out of the door?

In T228988#5471844, @Pchelolo wrote:

We have the batch API to grab revisions from rows and the batch API to fetch blobs T230834, but we haven't really connected the 2 together yet, so no, this is not entirely done.