sail again: https://github.com/wmde/wikidata-mismatch-finder/pull/621

types: https://github.com/wmde/wikidata-mismatch-finder/pull/620

Build related: https://github.com/wmde/wikidata-mismatch-finder/pull/618

This isn’t close to being done yet, I just didn’t want to put up additional PRs while the first ones were open.

In T338223#8906424, @Lucas_Werkmeister_WMDE wrote:

Maybe it would be simpler to instead implement another validator that asserts the repo name is empty in new edits, for instance?

Should be deployed now.

I think I just fixed that particular lexeme by pasting the result of

I think this needs to be deployed before it can be product verified (at least, it doesn’t seem to be fixed on https://query.wikidata.org/querybuilder/ yet).

Logstash for reqId 8217e332-56bf-4ec3-8d5e-4b78b07808d8:

Sail: https://github.com/wmde/wikidata-mismatch-finder/pull/617

ESLint: https://github.com/wmde/wikidata-mismatch-finder/pull/616

(While I’ve now gone down a bit further into the “let’s disallow nonempty repo names entity IDs” rabbit hole, that doesn’t have to be the only solution. Maybe it would be simpler to instead implement another validator that asserts the repo name is empty in new edits, for instance?)

I think this is resolved now.

Apparently we had already planned to remove support for “old federation” methods: T291823: Remove "old federation" methods from EntityId

In T338223#8905912, @gerritbot wrote:

Change 927654 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/Wikibase@master] Drop support for repo names in entity IDs

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

Okay, it is reproducible with { "entity-type": "item", "id": "foobar:Q50" } as the value in the wbeditentity payload. (If you leave foobar empty, i.e. "id": ":Q50", you just get a normal, working statement.) I expect this is related to the remnants of “entity IDs with repository names” that we still have in the code (before we decided to do federation differently), and I have a feeling it’s pretty much unrelated to the REST API issue.

I can’t reproduce this using the action API – both wbeditentity (as mentioned in the task description) and wbsetclaimvalue give me an error like this:

I think this is done.

This is deployed and the API result looks good now.

I think that’s it!

In T338213#8905384, @kostajh wrote:

Sorry, cs beta wiki: https://cs.wikipedia.beta.wmflabs.org/wiki/Speci%C3%A1ln%C3%AD:Uv%C3%ADtac%C3%AD_dotazn%C3%ADk

I think I actually found a fix for the original patch (though @daniel and/or @tstarling should definitely take a closer look) – let’s see if CI likes that. (But the revert can still finish going through gate-and-submit.)

In T338213#8905338, @kostajh wrote:

Hmm, beta wikis are offline too with a similar error:

[ZH73@OA1dX58GXh@K8XaKgAAAJA] /wiki/Main_Page Error: Call to undefined method MediaWiki\Extension\TorBlock\TorBlockAbuseFilterHooks::onAbuseFilter-builder()
...

This code is used for all hooks, it is exercised hundreds of times with every request, and most test cases. If somethign is wrong with it, we will know very soon.

Okay, I can reproduce it locally by running the Wikibase test repo/tests/phpunit/includes/Store/Sql/WikiPageEntityStoreTest.php --filter testDeleteEntity, and reverting “Simplify HookContainer” in core indeed fixes the test again.

Aha, we can get a PHP stack trace from the noselenium artifacts mw-error.log:

E.g. on this Wikibase change, several of the main test builds failed. The error message quoted above can be seen in selenium and in apitests, but neither of those give us a PHP stack trace unfortunately (unless it’s somewhere in the artifacts?); the noselenium job has plenty of errors, but eventually PHPUnit dies completely before it can print any of the details:

Possibly related to @daniel’s Simplify HookContainer? That was merged very recently, whereas I don’t see any recent changes in AbuseFilter or CentralAuth that look related at a glance. (From the error message, the simplified HookContainer might be missing some code to replace the - with _ in onAbuseFilter-generateUserVars?)

This is done, isn’t it? (The cleanup ApiListEntityUsage: Remove legacy prefix was attached to the sibling task T196962.)

Tested during deployment with this Wikidata sandbox item edit and this outreachwiki sandbox page edit.

I squashed the two remaining config changes into one (Make outreachwiki a multilingual Wikidata client), since I think it makes more sense to deploy them together anyways. Scheduled for the UTC afternoon deployment window later today.

In T332329#8899905, @Krinkle wrote:

I agree skipping a chainable method call is suboptimal, but I don't see a way to support that without a compromise. E.g. making the method nullable would introduce a significant surface for mistakes (footgun) with surprising side-effects that may be difficult to detect prior to affecting production.

Just ran into this again while trying to convert

Thanks, I didn’t know about that settings. But it looks like it only lets us inherit from one other group, not several?

Should the entry in Special:ListDatatypes also change accordingly? (Message: wikibase-listdatatypes-entity-schema-head)

Let’s leave some time for people to object on-wiki (maybe a week or so).

It turns out this task has also (like T337153) had some initial work done already: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/921633

Note: the vast majority of data providers in Wikibase are named either provideSomething or somethingProvider, so searching for public function provide or public function .*Provider\( should find the majority of functions that haven’t been converted yet. (git grep '@data[pP]rovider' | grep -v -e '@data[pP]rovider provide' -e '@data[pP]rovider .*Provider\b' shows a few dozen other data providers that are named differently; those will have to be checked manually whether they’re static or not, as it can’t be seen from the @dataProvider line.)

Stalled until 1.41.0-wmf.12 is fully rolled out, i.e. we can probably deploy the config change after June 12.

Stalled until 1.41.0-wmf.12 is fully rolled out, i.e. we can probably deploy the config change after June 12.

So, to recap the current changes I uploaded:

In T337717#8887895, @Lucas_Werkmeister_WMDE wrote:

(Though I suppose we could temporarily work around it in Wikibase with a Phan cast.)

Uggghhhh, but the needed MediaWiki core change fails with:

Ok, some of this is just that other parameter types need to be changed from IDatabase to IReadableDatabase, no big deal.

Grmbl, and ConnectionManager also isn’t as easy as I thought. It currently takes an ILoadBalancer, not an ILoadBalancerFactory; and Cognate (in its ServiceWiring.php) relies on the ability to pass in an external LB (if $wgCognateCluster is configured, which it is in production: extension1) rather than a main LB, so I don’t see how it can be migrated to the IConnectionProvider interface :(

In T336736#8855819, @Ladsgroup wrote:

And ItemsPerSiteBuilder which is used in a maint script which you can add $this->waitForReplication in that maint script and be done with it.

Seems to work fine in SpeedPatrolling, for example:

Looks like the fix is now deployed and working \o/

I think this is all done.

Hm, I can’t reproduce this in Chromium 113.0.5672.126 on Ubuntu 23.04.

In T337081#8881728, @Quiddity wrote:

For a few days earlier this month, the "Add interlanguage link" item in the Tools menu did not work properly. This has now been fixed.