In T367254#9892765, @taavi wrote:

That namespace does have deleted pages, can MW handle deleting a namespace with those in there?

In T369155#9948992, @Lucas_Werkmeister_WMDE wrote:

As for performance, if we backport this then I think we can look at ResourceLoader Module builds and see if there’s any visible effect from the deployment. (If this rolls out with the train, then the signal will probably be buried under noise from other changes in the train.)

As there were a lot of changes to deploy, I didn’t investigate yet, but just ran the script on mwmaint1002 instead.

Okay, I think we need two things:

Alright, if I load the CirrusSearch-related extensions and set all of the following settings, I can reproduce the issue on an item or property with EntitySchema statements:

Hm, are we just missing a search-index-data-formatter-callback data type definition?

I don’t see any P12861-related errors in Logstash that could explain this.

Sounds like our responsibility to fix, at least. Thanks for looking into it!

In T363243#9949529, @Stashbot wrote:

Mentioned in SAL (#wikimedia-operations) [2024-07-03T13:15:51Z] <Lucas_WMDE> lucaswerkmeister-wmde@mwmaint1002:~$ mwscript namespaceDupes kawikisource --fix # T363243; 34 pages to fix, 34 were resolvable; 774 links to fix, 774 were resolvable, 0 were deleted

In T369047#9949526, @Stashbot wrote:

Mentioned in SAL (#wikimedia-operations) [2024-07-03T13:14:25Z] <Lucas_WMDE> lucaswerkmeister-wmde@mwmaint1002:~$ mwscript namespaceDupes mswikisource --fix # T369047; 6 pages to fix, 6 were resolvable; 76 links to fix, 73 were resolvable, 3 were deleted

For future reference, the current cirrusDump contents are:

As for performance, if we backport this then I think we can look at ResourceLoader Module builds and see if there’s any visible effect from the deployment. (If this rolls out with the train, then the signal will probably be buried under noise from other changes in the train.)

Okay, I think I can reproduce the issue locally (looking whether entity-schema appears in mw.loader.using('wikibase.experts.modules').then(require => console.log(require('wikibase.experts.modules')))), and the above patch seems to fix it (no longer lags behind changes to $wgEntitySchemaEnableDatatype).

Could we force a re-index of this page?

Are you already deploying the backport now? Otherwise it shouldn’t have been merged yet IIUC.

Note to self and others: be very careful not to use the same metric name for two different metrics (probably, each ->getCounter(), ->getGauge() and ->getTiming() call in the code should have a unique literal string argument, except perhaps in cases like T359253). I thought I knew this already (it’s mentioned here and there in the statslib docs), and yet I still accidentally messed this up (see PS2..3 of the above change), and if I hadn’t tested locally that the jobs emit the same metrics before and after statslib migration, I never would’ve noticed that part of the stats was being quietly dropped.

In principle, we might be able to unblock the train by reverting the OOUI update; but I don’t know whether that’s okay to do or not (I asked here FWIW), and the people who can answer that are probably roughly the same people who can make a new OOUI release anyway, so I expect we may as well wait for the above change to be merged and released and then update to OOUI v0.50.3.

Yeah, the getBoundingClientRect() result has no own properties:

Well, somehow, just the following diff is enough to make it work again:

Hm, at a glance I didn’t see any Object.assign() calls where the first argument isn’t a fresh object (either an object literal or a variable that’s assigned an object literal or Object.assign() result earlier in the method body) in that diff. Maybe it’s one of the arrow function changes then, with a changed meaning of this?

A git bisect in OOUI points at build: Update eslint-config-wikimedia to 0.28.2 and autofix as the culprit, so I suspect one of the $.extend() ⇒ Object.assign() changes needs an extra {} argument in front (we’ve had other issues like this recently).

Yeah, I was thinking it might be.

Can also be reproduced with the log type or tag filters on https://en.wikipedia.beta.wmflabs.org/wiki/Special:Log?limit=1 (the ?limit=1 is important), so it’s not specific to Wikidata.

This seems to be a regression in OOUI 0.50.1 or 0.50.2 – I can reproduce it locally on Merge "Update OOUI to v0.50.2" (which bumps OOUI from 0.50.0 to 0.50.2) but not on its parent.

Screencast – I’m just repeatedly scrolling down:

I suspect that’s a true effect – the number of forms in the query service (14058347) matches the number in Grafana (14058150 as of midnight last night) extremely well.

This is probably an Upstream task, but I’m filing it here in case the email template is ours (IIRC we’ve had tasks about custom email templates before).

Another way is to generate a temporary app password via your personal gerrit.wikimedia.org settings, and use that instead. This however is not documented anywhere and afaik not what people would generally do.

Scheduled for today’s UTC afternoon window: https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20240701T1300

Can confirm this is fixed \o/

I can’t reproduce this either, but it sounds like someone else is having the same problem: https://www.wikidata.org/wiki/Wikidata:Report_a_technical_problem#Can't_escape_English

I’ve updated the documentation to hopefully make this clearer.

Somehow I managed to miss that this problem has, for most extensions, actually had a solution since 2016 (Gerrit change by @Legoktm, backported to REL1_27): You simply register the namespace in extension.json, but with "conditional": true. This will unconditionally set all the namespace-related globals ($wgContentNamespaces, $wgNamespaceContentModels, etc.), just as I already concluded should be done (T288819#7831800), except for registering the namespace itself – you do that, and only that, in the CanonicalNamespaces hook handler (based on whatever condition you want). This way, all the other globals will be set early enough that NamespaceInfo sees them, and you even get to use the nice and convenient syntax in extension.json. (This "conditional" flag has been documented since 2017, so I don’t know how I managed to miss it two years ago.)

I don’t think anything significant has happened to unstall this… it’s now clearer that the successor for Vuex, Pinia, should be used for new projects, and I think it’s assumed that eventually we’ll replace all Vuex usage with Pinia, but upgrading existing projects is not recommendet yet. More to the point, I don’t think we’ve done anything relevant in the Lexeme backend (moving more components to some store, whether Vuex or Pinia).

If this is causing major disruption I can messup with the index by hand but I'd rather not do that if not strictly required, sorry for the inconvenience!

I’m not really sure how this code could ever have worked:

Hm, though the search links in the task description still don’t yield the expected results :/

Alright, EntitySchema is a content namespace again. @dcausse, I guess we’ll have to reindex some recently touched EntitySchemas?

Assuming I’m not doing the search wrong, it looks like the namespace alias is unused on the wiki:

Pfft, and I just realized I duplicated @Pppery’s work there 🤦

In T368010#9925821, @Lucas_Werkmeister_WMDE wrote:

SomeMediaWikiComponent™ has already finished reading $wgContentNamespaces by the time our hook handler runs and adds 640 to it, and so the assignment is a no-op?

So this is fun. I tried to check how Lexeme solves the issue of declaring its dynamically registered namespace as content, and it just doesn’t. We add 120 (Property) and 146 (Lexeme) to $wgContentNamespaces in the production config, which is why they’re content namespaces there; other / third-party wikis apparently get to pound sand. (On my local wiki, the Lexeme namespace is not considered a content namespace.) IMHO we should fix this, but also in the meantime, let’s just add 640 to that production config block to make it content again.

I think the task I remembered was this one (slightly different but still feels similar): T288724: defaultcontentmodel missing from most namespaces in Wikidata namespaces siteinfo (breaks pywikibot)

Well, the patch you found looks like it’s supposed to still register EntitySchema as a content namespace… but I think I vaguely remember a similar issue from before, and it’s that SomeMediaWikiComponent™ has already finished reading $wgContentNamespaces by the time our hook handler runs and adds 640 to it, and so the assignment is a no-op?

Logstash link for non-termstore deadlocks (I think they’re roughly evenly split between addUsages and removeUsages): https://logstash.wikimedia.org/goto/20ade51dc3a72b8b8234467babe021cf

Add cloudflare to the list of seemingly affected upstreams (build):

Seen in another build:

In T368385#9921825, @kostajh wrote:

Is it possible to specify a fallback source (e.g. some mirror that hosts this code) with ForeignResourceManager that is then only used in CI context?

In T362425#9921033, @Lucas_Werkmeister_WMDE wrote:

I just filed the jQuery version at T368385 as well; not sure if it makes sense to track separately or should be considered a duplicate, TBH.

That’s a huge number of queued changes that are all going to fail, one by one, because the fix needed a second patch set… :blobfoxnotlikethisgoogly:

BTW, I also remember occasionally getting this failure… maybe ForeignResourceManager should retry the download once or twice if it fails? (AFAICT it’s never called during normal requests, so the potential extra runtime shouldn’t be a production concern, I think.)

I guess the expected output just needs to be updated after red-link-title was changed on TranslateWiki.net? https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1049387/1/languages/i18n/ar.json

I just filed the jQuery version at T368385 as well; not sure if it makes sense to track separately or should be considered a duplicate, TBH.

If I’m not mistaken, the difference is between غير (expected) and مو (actual) in both lines.

Tagging 3D after all – I doubt the relevant WikibaseQualityConstraints or WikibaseMediaInfo code has changed much recently, and at least the mediainfoview error is a known long-standing issue: T321532 – IMHO this error is more likely due to be due to some recent refactorings in 3D (e.g. es6 changes)

I think this task would become obsolete with the completion of T343020: Converting MediaWiki Metrics to StatsLib – statslib doesn’t use this library AFAICT (it directly uses the sockets extension in \Wikimedia\IPUtils\UDPTransport::emit()).