And just to confirm – alternatively, this patch in MediaWiki core also fixes the error locally:

Well, this alternative approach works to fix the tests (at least locally):

The failing code is here:

The "maintenance/" prefix is added before that check

In the meantime, the workaround is to continue including ".php" when not mentioning a wiki.

• Who will be in charge of deploying the wikidata-query-gui service in the future? A bit of onboarding to the new Kubernetes deployment process might be needed.

(For all I know, this might not actually be an issue in mwscript-k8s – perhaps it’s somewhere in MWScript.php or elsewhere in the multiversion machinery? No idea.)

I assume that the input on stdin option should work in theory:

However, the selenium screenshot clearly shows there are edit buttons on the "old revision" page when there shouldn't be:

Well, immediately after I posted that message the circuit breaking errors seemingly went away after all (last seen Oct 2, 2024 @ 13:01:22.661). 🤷

In T376249#10195642, @Ladsgroup wrote:

It's resolved already: https://logstash.wikimedia.org/goto/a0ba42b64d7c18fa6fcdd963752140e4

Pull request: https://github.com/wmde/new-lexeme-special-page/pull/773

In T350793#10195486, @Jelto wrote:

Currently, it would be just one release with a single Wikidata GUI. I'm not entirely sure how the separation between the different Wikidata services is implemented. Depending on whether it's managed through configuration (like environment variables) or different code/builds, we could add more releases for the other services.

Probably not, Patch Demo doesn’t support Wikibase (#552).

In T370052#10190492, @ArthurTaylor wrote:

we can make the current set of changes live and you can review them on beta and give us feedback before they hit production. (Or after they hit production, but obviously it's a slightly worse user experience in that case if we have subsequently to make changes based on your feedback).

Should we activate the current set of changes for deployment to beta (and production) so that you can review?

Because of the process to connect this wiki with SUL you have to request a temporary password

I believe this should be set as the default for the CdxMenuButton component?

Hm, but I don’t see any OutputPageEditabilityTest errors in the CI output of PS2 there? It looks like a bunch of other errors now? (At least some of which, like “Requested page AbuseFilter testing page isn't in the wikitext content model”, feel like they might also be due to the main namespace no longer being wikitext.)

All three failing tests use an NS_MAIN title, so at a guess, WikiLambda probably changes the interpretation of that namespace?

Can we see if ^ helps? Would Depends-On on the Quibble change work?

Should be live here: https://d3002abfe74c2432e92dcb465ca996082011--new-lexeme-special-page.netlify.app/

Thanks, not sure why I couldn’t find the existing task.

In T375472#10170293, @So9q wrote:

Evaluation by chatgpt4o:

https://github.com/wmde/new-lexeme-special-page/pull/765

Sounds great, thanks!

I’ve split off the remaining design token work into T375370: [WtC-M3] [SNL] [Investigation] Determine best long-term solution for using Codex design tokens in Special:NewLexeme; with that, I think this is done.

Alright, thanks for clarifying :)

@ItamarWMDE for the remaining work (find out where the regression is so we can update other libraries and maybe work around the issue or report it upstream if applicable), should we leave the task on the Wikidata Dev Team (Wikidata.org Slice) board or punt it over to Wikidata Dev Team (Quality Tools "Sprint")? (If we leave it here, then IIUC it doesn’t actually belong in Ready for Tech Verification yet.)

I feel like this task is missing an equivalent of T358286: SRE comms for Northward Datacentre Switchover (March 2024), is that intentional? For instance, the switchover hasn’t currently been added to the deployment calendar (permalink) as far as I can tell. (If someone wants to add it to the calendar and is wondering what the wikitext should look like, this old revision may be useful.)

The icon is added here:

Thanks for unfooing the server ;P

I have frankly no idea what tags to add to this… ops-eqiad is just a wild guess. But given that it happened twice, it feels worth investigating by someone™.

🤷

Hm, after a purge it went away again. Transient issue?

Same as T373385: Parsoid doesn't generate the broken-file-category tracking category? (Noticed while looking for another task on the board.)

In T368654#10156498, @Joe wrote:

Yeah that is slightly surprising

https://github.com/wmde/new-lexeme-special-page/pull/761

I think this outcome is to be expected if the message doesn’t use [$1 link text] syntax (probably by accident):

Fix should be live now (you might need to purge affected items).

I don’t think we have any specific access numbers. If the limits are reasonably high, I think we’ll just have to hope for the best – it doesn’t sound like we have other options anyway.

I don’t think that’s relevant, it happens on any query that uses named subqueries (can’t be parsed by SPARQL.js). The relevant error is probably this one:

Well, partially reverting the package-lock.json changes seems to work, though I don’t yet know what exactly the issue was…

Aha, but I can reproduce the problem locally (“Unable to display result: Area chart”) when using the build! (After npx grunt only_build and npm run start, open http://localhost:8080/build/ rather than http://localhost:8080/.)

Might have been broken by one of the recent package upgrades.

Maybe it happens because property 6615, which was used in a statement on that item, was deleted a couple of months ago. The statement was deleted, too, and it's not even the latest edit on the item. In any case, such a thing probably shouldn't cause the whole script to crash.

(No idea what a good tag for this task would be, to be honest. Wikimedia-Site-requests is my best guess.)

(I’m backporting the fix now because I feel like it’s awkward if the SSR is out of sync for so long, even though I don’t think it causes any technical issues. And also getting MUL improvements into the community’s hands is nice anyway.)

This is now deployed for the server-side termbox and will roll out for the client-side termbox with next week’s train (unless we backport it this week).

(Interesting output starts at line 40 – I just realized I included the git show command by accident. Might as well keep it for context, I suppose.)

Observed after the Puppet 7 migration of deploy1003. (I don’t know for sure that it’s related but it seems likely enough.) The image version diff is expected (Gerrit change), the certificate change isn’t. (Also, note that it changed from one certificate to two certificates. I have no idea if that’s significant.)

Also planned as part of T374926: [EPIC][Infra] Move Wikibase and WikibaseLexeme Git submodules to suitable Git host for other reasons; I’m not sure how we should best relate these tasks to each other, to be honest.