Probably needs discussion and re-architecting. Note that php interfaces cannot really be refactored, they can only be replaced.
This doesn't seem immediately actionable, and thus unsuitable as a clinic duty ticket. May make more sense to track this as a future initiative, or an rfc.

In T235551#5595271, @eprodromou wrote:

So, it seems to me and @CCicalese_WMF that this has impact on our Commons servers, and would be helpful for remote MediaWiki sites using Instant Commons. It's not clear why turning off caching was helpful for anyone.

Probably introduced by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/543718. Pinging @Pchelolo.

In T224949#5653825, @MarkAHershberger wrote:

Could you clarify what sounds risky? Is it the use of mwdumper? Or my automation?

In T224949#5637909, @MarkAHershberger wrote:

You can see the exact process I used here. I used these tools to create an SQL dump that I then loaded with mysql's cli.

Config patch scheduled to be deployed on November 12.

this logic should be folded into RevisionStore::getQueryInfo() or an associated method. RevisionStore provides encapsulation for the schema of the revision table, so that's where this logic should live.

In T237049#5632750, @Jdforrester-WMF wrote:

@daniel is probably needed to fix this, sorry.

@zeljkofilipin suggested to move only the tests proper into the core repo, and leave the framework in a separate repo. We'd publish the framework as an npm package and add it as a dependency to core's package.json file. We'd also add a command for running these tests to core's package.json file, and trigger them from quibble, just like we do for selenium.

After discussing this with Cindy, we decided to push this back. While we still want a solution that provides some kind of "deterministic mode" for interaction with MediaWiki, this is not a problem for tests in practice if we poll and wait for job execution anyway.

In T224949#5629556, @MarkAHershberger wrote:

@daniel: it happened before and after. I upgraded to see if the fixes here would fix this issue.

@MarkAHershberger Does this happen while upgrading, or after? Where there any errors reported during the upgrade?

In T234636#5569741, @TheDJ wrote:

What is the problem that led to this session proposal ?

@kostajh suggested to move the API integration test infrastructure into the MW core repo, along with the tests themselves. We already have this kind of situation for phpunit, qunit, phan, and selenium, so why not for mocha?

In T235955#5616151, @Anomie wrote:

An object to wrap a single string seems like overkill to me.

In T233537#5616013, @Anomie wrote:

I see no mention of such an understanding at https://www.php.net/JsonSerializable or https://www.php.net/manual/en/jsonserializable.jsonserialize.php. And json_decode() still wouldn't round-trip it.

PHP serialization will often round-trip it while JSON never will (whether it's JSONSerializable or not).

In T235955#5592295, @Anomie wrote:

IMO the exposure of "db domains" outside of internal LoadBalancer→Database communication was and is a bad idea. Most of the code should consider "wiki ids" as opaque strings. The public interfaces of LBFactory, LoadBalancer, and Database should follow suit.

Bug fixed, see T236735: Allow WikiExporter to function with MCR-only schema.

Fixed, confirmed on beta:
https://en.wikipedia.beta.wmflabs.org/wiki/Special:Export/0.42323637011943815

if you post without a version ID, you are signalling that you want to create a new page, which will cause a conflict if the page doesn't already exist.

if you post without a version ID, you are signalling that you want to create a new page, which will cause a conflict if the page doesn't already exist.

All subtasks are resolved. I just went over the remaining open patches for this task and abandoned a few obsolete ones. There are only two patches remaining open, one for the Duplicator extension and one for the DeletePagesForGood extension. Neither of these is supported by WMF (deployed or bundled).

In T231673#5471838, @Jdforrester-WMF wrote:

That means that this task should be blocked by a task for fixing the remaining usages… presumably T231671: [EPIC] Ensure all direct or indirect access to pre-MCR fields is gated with the MCR migration stage and emits a warning if any pre-MCR schema fields are accessed?

Stack trace:

Re-opening. This broke Special:Export, see e.g.
https://en.wikipedia.beta.wmflabs.org/wiki/Special:Export/0.42323637011943815

Config change was reverted, since it broke Special:Export.

I recall that we had long discussions about this when initially deciding on the data model. In technical terms, the question was whether we would allow only a single literal value for a spelling variant, or a list or set of words. Allowing a list or set would enable the kind of flexibility @jhsoby is asking for. But the down side is that it introduces ambiguity when listing forms (you would always have to list all of them, in undefined order), and when generating text (which one should you use)?

https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/543007

I assume this is resolved now. Please re-open as needed.

What's the ask for CPT here?

closing per @RobinHood70's comment

Going by the comments, this sounds like imports causing lock retention on the page table. Needs further investigation.

Looks like both linked tasks need review/merging.

I'm having a hard time finding any other public API (besides Action API and RESTBase) that include CSRF tokens. I'll see if I can do some more research to come up with how other providers do it.

In T235528#5575718, @eprodromou wrote:

@daniel You say "pages", but this endpoint is defined for comparison across revisions of a single page. I assume we need one permission check for the page, and a second and third for each revision?

In T233178#5574532, @ArielGlenn wrote:

I have found the reason for triple lookups of content; the third lookup, performed from within the Abstract Filter extension, is to determine whether or not the revision is a redirect or not.

Thank you for investigating, Ariel!

Pinging Performance-Team since they own WANObjectCache.

I put this up for SWAT in 3 hours: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/542963

The handler for this route doesn't seem to check read permissions for the pages it is comparing. That means it could be used to bypass per-page read permissions. The DifferenceEngine class responsible for showing diffs in the UI does apply these checks, though I note that ApiComparePages seems to be lacking them as well.

On the patch @BPirkle asked:

Thank you Daniel. Was that comment informational, or did you see something we need to change?