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.

Steps to reproduce (based on T326768#10152076):

Okay, the error is definitely back in the logs (example logstash entry), and I figured out how to reproduce it \o/

Seems to be fixed \o/

Hm, I think I dropped the ball on this after clicking +2. I think we need both of the following:

AFAIK the Gerrit changes are ready for review; I think I meant to ask someone from Wikidata Dev Team (Wikidata.org Slice) for review but forgot :/ given that I changed the gui-deploy changes quite a bit from what Itamar uploaded, I don’t think I should merge those on my own.

Previously (no idea if related): T137460, T152340

The core change still needs to be reviewed; IMHO it’s harmless enough that it would be fine for someone from our team to merge it, but I also wouldn’t mind if a WMF person does it ^^

Do we need to change anything so that we can use Codex in this environment?

Other possible approaches to fix the test might include:

I tried to look through the Git log but didn’t really find what I was looking for; the closest changes were service wiring changes for RecentChangeFactory and SiteGroup.

Already fixed by @matmarex in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlaggedRevs/+/1072198 AFAICT.

Though it’s not clear to me why that change makes a difference for the Wikibase test.

FTR, judging by this other change the failure only seems to affect the change linked in the task description, not WikimediaMessages CI in general. Though it’s not clear to me why that change makes a difference for the Wikibase test.

I assume this means that the REST API […] doesn’t redirect the user to loginwiki

In T368654#10137263, @Joe wrote:

Special pages are not cached at the edge, so there is no caching for that url, independently of indicating a revision or not:

$ curl -Is https://www.wikidata.org/wiki/Special:EntityData/Q42.json  | grep cache-control
cache-control: private, s-maxage=0, max-age=0, must-revalidate
$ curl -Is https://www.wikidata.org/wiki/Special:EntityData/Q42.json?revision=1600533266  | grep cache-control
cache-control: private, s-maxage=0, max-age=0, must-revalidate