Software developer on the Wikidata team at Wikimedia Germany (he/him, Berlin timezone). Private account: @LucasWerkmeister.
User Details
- User Since
- Apr 3 2017, 2:45 PM (322 w, 2 d)
- Availability
- Available
- IRC Nick
- Lucas_WMDE
- LDAP User
- Lucas Werkmeister (WMDE)
- MediaWiki User
- Lucas Werkmeister (WMDE) [ Global Accounts ]
Yesterday
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.
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).
Tue, Jun 6
(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
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!
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.)
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.)
Mon, Jun 5
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.
Fri, Jun 2
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?
Thu, Jun 1
Wed, May 31
Should the entry in Special:ListDatatypes also change accordingly? (Message: wikibase-listdatatypes-entity-schema-head)
Tue, May 30
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:
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.
Fri, May 26
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 :(
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.