FWIW, the query works quickly for me if I inline the ?item variable or the ?class variable (or both). Given that ?class may have multiple values, inlining ?item is probably the best workaround in WBQC (I’m not sure why this used BIND() to begin with, to be honest).

In T429005#12173231, @MusikAnimal wrote:

https://integration.wikimedia.org/ci/job/quibble-with-Wikibase-extensions-browser-tests-only-vendor-php83/16408/console

After two rechecks it passed. I thought the failure looked more like T418778 but T418778#12013553 suggests this is the right task.

For anyone who wants to test this: the expected result of the change I wanted to deploy is that you can

The deployment window is done and I have mostly good news! I documented the results (with mw-collapsible ab outputs) on wiki. Relative to the plan from T231755#11884157:

I think this task can be resolved (I just completed the last bits of T424098).

In T424098#11884831, @WMDE-leszek wrote:

Github repository will be archived once https://github.com/wmde/new-lexeme-special-page/pull/837 got merged

Same thing happens when trying to connect to staging.svc.eqiad.wmnet on port 8081; the host can be pinged, but not connected to, via IPv6:

Code pointer: in the API output code, the URLs are added with injectEntitySerializationWithSiteLinkUrls(), which boils down to simply $site->getPageUrl().

In T428231#12144807, @Jonathanischoice wrote:

Hi @Lucas_Werkmeister_WMDE - I'm having trouble reproducing this (and I'm not sure why you'd want display_errors=1 like it's 1999 😄).

In T432578#12136985, @Pfps wrote:

The "why" seems obvious - the WDQS label service is a non-standard construct that violates the assumptions built into the SPARQL SERVICE construct.

If there have been no known occurrences of this error since @kostajh’s suggested fix was merged on 10 July (over two weeks ago), we can probably remove the debug output again and then close this task?

Hm, one thing I hadn’t thought about yet is where to deploy this – which train branch do we target, and which wiki do we test the performance on?

Deployment window scheduled for Wednesday 15:00–17:00 UTC.

In T231755#12105432, @Nikerabbit wrote:

I think we could proceed as is. No idea how long it might take for the other task to complete.

The especially interesting question will be where the cache invalidation happens, and how we can do it – ideally, we would have a diff of the property edit available at that point

In that profile, it takes only 2% of the load time but I can imagine in larger items, it'll start to add up.

(I’m not actually sure “flaky” is the right word here – this might just be deterministically broken? As it’s in the Score extension, not in Wikibase itself.)

Copying over this explanation from the commit message:

⇒ T431574: Flaky Cypress test: add score statement - mobile view - loads the item view…: expected to find .wikibase-wbui2025-edit-statement-snak-value input, .wikibase-wbui2025-edit-statement-snak-value textarea

Thanks, now we have a screenshot: https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php83-selenium/65543/artifact/log/Score/editAndAddScoreStatement.cy.ts/add%20score%20statement%20--%20mobile%20view%20--%20loads%20the%20item%20view,%20allows%20statements%20to%20be%20edited%20and%20new%20statements%20to%20be%20added%20(failed).png – looks like a new issue to me (related to T424009), so let’s keep this closed and I’ll make a new task for that.

In T418778#12037128, @Lucas_Werkmeister_WMDE wrote:

(That said, I have no idea why document.getElementById( 'wikibase-wbui2025-statementgrouplistview' ) would sometimes return null – we can see a <div id="wikibase-wbui2025-statementgrouplistview"> in the console-logged HTML – and fixing the condition in entityViewInit.js won’t fix the error, it’ll just result in a different message, as far as I can tell.)

Also, we’ve already skipped the test that this task was originally about (“tabular-data qualifier”). And as mentioned in T418778#12045015 T418778#12058921, the only effect of that has been to shift the failure to the next test (“geo-shape”). Which is now failing in exactly the same way, except with none of the debug output, because all the debug output that we added to try to make sense of this error is in the test which is now skipped. So we’ve just made it harder to figure out what’s actually going wrong, without actually making the test any less flaky.

In T418778#12099322, @kostajh wrote:

https://integration.wikimedia.org/ci/job/quibble-with-Wikibase-extensions-browser-tests-only-vendor-php83/14463/console can we please disable this test?

The job still exists, but the build time trend only goes back 20 hours (#65366 is the latest build still present at the moment). No idea where the other builds went – and without the Cypress screenshots it’ll be tough to figure out what went wrong in that build :/

In T425845#12094129, @Reedy wrote:

https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php83-selenium/65284/console

Every Wikibase uses production Commons, because the data type is commonsMedia, not local media. (I’m guessing it tries to serve a local thumbnail because that’s how InstantCommons works, or something along those lines.)

In T231755#11886313, @Nikerabbit wrote:

You're probably aware, but noting that there might be some interaction with T99740: Use static php array files for l10n cache at WMF (instead of CDB) with regards to performance.

We got an email from EntitySchema secondary CI today, so it looks like the password revert was successful.

The only log output I’m aware of, besides the videos and screenshots, is in the console, yes.

In T429054#12054055, @AudreyPenven_WMDE wrote:

the patch for WikibaseMediaInfo is failing in CI, more work is needed to figure out exactly why, and to fix it

I still can’t reproduce it in Firefox’ Responsive Design Mode. Is this a Chrome-only issue?

In theory, the issue should still be reproducible on Wikidata (because the fix was merged after the branch cut for this week), with the fix on Beta Wikidata; however, I can’t reproduce the issue on Wikidata at the moment (the reference snak already has the right height as soon as I expand it). Can anyone else?

(accidental closure, I think?)

I expect it would at least be necessary for it; additionally, WBS would probably have to configure the URL shortener in custom-config.js. (I don’t think we want to assume the wiki has UrlShortener installed in default-config.js – unless WBS changes the WDQS-GUI default-config.js?)

We’ve already changed the error message to some extent (with the more recent changes in T412145), maybe that helps to see what our constraints are:

Seems to be somewhat flaky, for what it’s worth…

(That said, I have no idea why document.getElementById( 'wikibase-wbui2025-statementgrouplistview' ) would sometimes return null – we can see a <div id="wikibase-wbui2025-statementgrouplistview"> in the console-logged HTML – and fixing the condition in entityViewInit.js won’t fix the error, it’ll just result in a different message, as far as I can tell.)

In T418778#12036891, @gerritbot wrote:

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

[mediawiki/extensions/Wikibase@master] Make ResourceLoader errors visible to Cypress

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

And now I’m getting the same error in non-debug mode; at least I think this is the same “no active Pinia” error ((t=n)._s.has(a) in pinia.iife.prod.js seems to correspond to pinia = activePinia; if (!pinia._s.has(id)) in pinia.iife.js):

The stack trace indicates this is related to our WikiProjects work (SidebarBeforeOutputHookHandler::addWikiProjectLinks() calling RedirectResolvingEntityLookup::getEntity()).

Looks similar to T428649, might be related?

I suspect this was caused by our recent Special:EntityData refactoring for T98035.

I’m thinking we want to override or instrument mw.trackError() (which RL calls when a module has an error) to make the error visible to Cypress; just throwing an error might not work (because it’s caught again), but something like Promise.reject( msg ), triggering an uncaught promise rejection, might work? (Assuming Cypress registers a window.onunhandledrejection handler.)

Actually, that’s a good point. I imagine it should be possible to let MediaWiki connect directly to an internal WCQS instance, bypassing the authenticating proxy, just like WBQC connects to an internal WDQS instance. (We might want to tweak the query a bit so the result can be sensibly described – “used X times as a value, Y times as a qualifier, Z times in a reference” or whatever.)

Aha, there we go! (From the video, 0:37)

In T429345#12032679, @karapayneWMDE wrote:

From Task Time: @Arian_Bozorg

• How is the number calculated. Is it really only items?

In T429054#12029550, @Lucas_Werkmeister_WMDE wrote:

WikibaseMediaInfo only loads the former, but directly inserts the messages, which are now missing.

Aha, in Do not load oojs-ui for the new mobile (MEX) interface (T400325, T423901) we moved those messages from the wikibase.quality.constraints.ui RL module to the new wikibase.quality.constraints.gadget module; WikibaseMediaInfo only loads the former, but directly inserts the messages, which are now missing. Oops.

Thanks, I can reproduce the issue on https://commons.wikimedia.org/wiki/File:PNG_Test.png (until someone removes the statement again).

In T420865#12022630, @ArthurTaylor wrote:

I'm still seeing a bunch of Recv failures / connection resets: https://integration.wikimedia.org/ci/job/quibble-with-gated-extensions-vendor-mysql-php83/41139/console . I've tried to merge 5 patches this morning and hit this issue on gate-and-submit for every single one of them.

This CI build failed with a very similar error:

In T428620#12024194, @awight wrote:

• However, visiting the MediaInfo item on Wikidata by following the provided link on the edit page fails: https://www.wikidata.org/wiki/Special:EntityPage/M188621501

@Reedy steps to reproduce? URL? anything?

That might be better, yeah, since it’s not limited to popups:

Note: T428620, a task causing heavy logspam (including “MediaWikiHighErrorRate: Elevated rate of MediaWiki errors - kube-mw-api-ext” alerts, I gather), is currently worked around only on the wmf.6 branch. It only affects commonswiki, and we’re hoping to have a proper fix merged (and, if necessary, backported) to wmf.7 before that branch reaches group1; but if the logspam causes problems, you may want to backport the workaround to wmf.7 as well.

The logspam should be fixed, for now; the task remains open for the proper fix.

Note that this also means that, for something approaching seven years (since MediaInfo specific Lua modules), there’s been a gaping hole in usage tracking on Commons: you can completely bypass statement usage tracking by accessing .statements instead of .claims. Fortunately, the impact of this should be limited, because:

In T428620#12014233, @Lucas_Werkmeister_WMDE wrote:

but WikibaseMediaInfo entities don’t have claims! they have statements! it’s the gift that keeps on giving (in the form of more and more Phabricator tasks) – see e.g. T149410

aaaaaaaaa I bet I know what it is

I added an ad-hoc debug message on mw-experimental:

I notice that a lot of the request URLs in Logstash (insofar as we have them at all – many requests are api.php POSTs) seem to point to DPLA files (random example – though this could also just be because we have many DPLA files on Commons), and the Module:DPLA history (found via RecentChangesLinked) has some edits around 9 June (when we started seeing this error at a larger scale, if I’m not mistaken).

In T428512#11999104, @Ladsgroup wrote:

Plus once the label of property changes, it takes a while to be reflected on all items since HTML of the page is stored in ParserCache for a month

Termbox shouldn’t be used on Commons, so I’d be very surprised if that’s related. (Also, the errors seem to show up in Logstash at least half a day before the 2026-06-09 Termbox deploys).

FWIW, when I had a quick look at the stack trace the other day, none of the code seemed to have been touched recently. I also don’t understand the code well enough to judge if this is missing some form of array_key_exists() check, or if it’s correct that the code always excepts the C (claims/statements) usage to be present, and some other issue is violating that expectation / precondition.

This could be the same error as T418778, in that it’s the [data-v-app] part of the selector which is missing (but in the screenshot we still see the P23 text because it’s server-side rendered).

Test was relatively recently added in MEX Handle deleted properties (T402619: [MEX] M5 - add functionality for when edit form is opened on a deleted property).

In T418778#12012990, @Krinkle wrote:

And again. This time not the exact same test?

https://integration.wikimedia.org/ci/job/quibble-with-Wikibase-extensions-browser-tests-only-vendor-php83/11208/console