I doubt it’s the “correct” solution, but FWIW, this seems to work to avoid the error:

I’m not sure if this task is a blocker for T332157: [ES-M2]: Enable new EntitySchema data type on Wikidata or not, so for now I just made it a subtask of T214884: [ES-M2]: [EPIC] Linking EntitySchemas in statements, since it clearly seems related to that (though I don’t think it has to block it either). If we don’t implement this, then edit summaries for EntitySchema values will probably just show a plain text English label or the EntitySchema ID.

Per T324202#9744647, I think we can go ahead with this now. (The train hasn’t reached group2 yet, but I feel confident enough after seeing no problems on group0 and group1. And tomorrow I’ll be busy with non-tech things all day, so I want to give the green light today ^^)

In T324202#9302370, @Lucas_Werkmeister_WMDE wrote:

Given that this cache is (AFAICT) used among other things for the term store / formatter cache, where it has a very high absolute hit rate (over a million hits per minute) and a pretty good relative hit rate (ca. 98%), I don’t think we can afford to just switch out the cache key without having some kind of fallback for the old value, unfortunately.

Prio note: We’re not sure how to prioritize this (which team is responsible for Property Suggester?), but as it should be a pretty small task, let’s just put it on top of the backlog.

@Arian_Bozorg probably something for the product side – do we want to do this or not? (Right now, I’m not even sure what the message does, to be honest.)

Can be tried out on Test Wikipedia: https://test.wikipedia.org/wiki/Human (using data from the connected Test Wikidata item).

Seems to be working better now on Beta \o/

I tried fixing this by just copying the padding-bottom + margin-bottom rules into -top versions, but testing it locally, I’m not sure it’s really helping – the flyout just gets further away from the button then :/

I think we have a few different options to implement this:

I guess this is almost a duplicate of T168365: Use new standard MediaWiki error reporting with Wikibase API and/or T168367: Disable custom error reporting in the API if new error format is requested. – I hadn’t seen those tasks before.

It looks like it’s possible to get similar information out of Kubernetes:

Maybe we can work on this during the hackathon? I’ve heard a few interested people will be there :)

Yeah, it feels like the sort of tool it could be quite useful for.

I’ve squashed the above change into the Gerrit change that introduces the class; moving to peer review in case someone wants to take a look, but I don’t think it needs a lot more time spent on it :)

Easy enough to fix:

In T362653#9722788, @Stashbot wrote:

Mentioned in SAL (#wikimedia-operations) [2024-04-17T15:04:21Z] <Lucas_WMDE> lucaswerkmeister-wmde@mwmaint1002:~$ mwscript namespaceDupes mlwiki --fix # T362653: 0 pages to fix, 0 were resolvable; 82 links to fix, 82 were resolvable, 0 were deleted.

I actually can’t reproduce this at all anymore. Let’s just chalk it up to the WIP-ness of the previous patches (which are now less WIP – I’m testing Wikibase 1ff1c5334f and EntitySchema 8f0596f2f1) and close it as invalid. If the problem comes back we can reopen the task or create a new one.

This is probably a side effect of us not having a real “expert” yet (T362004). I’ll see if I can hack together a sham expert to confirm this theory.

In T354597#9722424, @gerritbot wrote:

Change #1015295 merged by jenkins-bot:

[operations/mediawiki-config@master] WikimediaEvents: Set IPoid URL and enable ip_reputation/score

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

It looks like the above three changes are enough to make PHP 8.2 and 8.3 pass \o/

Previous bastions had (due to the grid) all the locales which I'd like to avoid.

I also get a locale error (“manpath: can't set the locale; make sure $LC_* and $LANG are correct”) when connecting to toolforge-dev with normal SSH:

Is this still an UBN? I’m not really sure how the above two patches relate to this.

There are a bunch of additional failures in this build (for this change) (from this video); some of them look like they don’t really require separate tasks, so let’s attach some fixes directly here, I think.

Prio Notes:

Prio Notes:

Prio Notes:

It’s documented here, by the way: https://www.mediawiki.org/wiki/Manual:Collapsible_elements#Custom_toggle_link_placement

Okay, I see. Anyway – we should definitely be able to document the props (even if there’s just one of them at the moment) – see the query+info docs for comparison: MediaWiki supports adding a documentation message for each supported value.

Apparently this was still open and assigned to me… let’s assume it’s fixed, feel free to reopen otherwise. (There’s been some movement in these browser tests anyways, e.g. they’ve been ported to async mode in T300807.)

@thiemowmde can you see if it works better now?

In T362505#9712645, @gerritbot wrote:

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

[mediawiki/extensions/Wikibase@master] DataBridgeReferenceFormatter: Use message as text

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

Yeah, I think the other test failure in the linked CI build (“Expectation failed for method name is "addCategory" when invoked 1 time(s).”) also would make some sense with a broken message cache – in that case, TrackingCategories might resolve the tracking category to an empty / disabled category, and therefore not call addCategory() on the ParserOutput.

Wikibase’s own CI seems to be working at least, https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/1019064 was merged just an hour ago.

Scratch all that, my Cite was just outdated. After updating it I can’t reproduce the error anymore.

Yeah, splitting the job also sounds fine to me.

(why would you pass an empty value?)

Locally, git bisect says the first bad commit is Deprecate use of dynamic properties attached to Parser (T343227). However, it fails with an error Use of MediaWiki\Parser\Parser::$extCite was deprecated in MediaWiki 1.42. that I don’t see in the linked CI output.

In T362412#9710114, @Lucas_Werkmeister_WMDE wrote:

• make those jobs run on PHP 8.1 on all branches (After all, we still have other CI jobs to cover PHP 7.4 compatibility while we need it for production.)

(Probably not a blocker for the release, just related to it.)

Potential options: