Note the File:Undefined from https://it.wikipedia.org/wiki/Timor_Est?useparsoid=1 while verifying T346703#9204822

Alas, this is going to need a new release of Timestamp similar to T329594

The train has reached itwiki and the TMH player is now loaded on,
https://it.wikipedia.org/wiki/Timor_Est?useparsoid=1

An attempt at this was started in,
https://github.com/wikimedia/mediawiki-services-parsoid/commit/55da3090d0e7faa49e40a5bce0f68634fea5fc83

@phuedx Thank you

It looks like the question mark is forcing this as an extlink,

I actually need three of them to trigger the issue:

Note that you can produce the same error with,

From what I can tell, a fairly routine The maximum execution time of 60 seconds was exceeded RequestTimeoutException was thrown by Excimer while inside the try block creating a DateTime,

Post-deploy, there is no longer forstered content lint for,
https://en.wikisource.org/w/index.php?title=User:Arlolra/sandbox&oldid=13383266

There haven't been any instances post-deploy yesterday, though there used to be days of zero occurrence regardless. I'll be optimistic in closing and check back on it later.

Parsoid's output looks ok
https://en.wikipedia.org/api/rest_v1/page/html/Abbey_Road#Track_listing

So if I were to write the following some time ago I would also get a broken result?

Sorry, there are two wikitext parsers in MediaWiki. The "legacy parser" is the one that still produces what you'd see in a desktop browser.

Here's a simplified test case from the reqId,

This has previously been filed as T264226 and T256913, but looks like it was closed without investigation.

The crucial piece you're tripping on here is || in the file link [[Tập tin:Hellenic Army War Flag.svg|23x20px||alt=|link=]]

Another path may be to add a later hook for that sort of cases.

However, in the parse direction, the metrics are only emitted in ParsoidHandler::wt2html, so calls to DirectParsoidClient::getPageHtml / transformWikitext aren't recording any data. They should be moved somewhere inside HtmlOutputRendererHelper or whatever it calls.

...

That leaves RESTBase. It's still being populated for the other endpoints that depend on it, which continues to make call to the ParsoidHandler, accounting for the data we see.

Post-deploy, data is starting to repopulate https://grafana.wikimedia.org/d/000000046/parsoid-timing-html2wt

In T339365#9132448, @Arlolra wrote:

Something is amiss with selser and needs investigating next.

Previous to the switch, all serialization was done on the Parsoid cluster. Now, each app server is doing that work and all those servers aren't instantiating statsd with the same prefix as they used to (MediaWiki vs MediaWiki.Parsoid).

Interesting, that patch fails because of the test added in,
https://github.com/wikimedia/mediawiki/commit/79cc21beaf34c82f368ef88125bcdd2567a8f389

I tried adding equivalent queries with both prefixes to the graphs, for continuity, but because not all the data goes to zero for all graphs, it was kind of a mess. Instead, I duplicated the dashboard with a -direct postfix,
https://grafana.wikimedia.org/d/000000046/parsoid-timing-html2wt?orgId=1&refresh=30s&from=now-6M&to=now
https://grafana.wikimedia.org/d/xxRCkIzIk/parsoid-timing-html2wt-direct?orgId=1&refresh=30s&from=now-6M&to=now

At first blush, it's unclear why switching VE away from RESTBase would only affect the html2wt metrics since the DirectParsoidClient calls Parsoid directly in both directions.

5. Add [rel=mw:referencedBy] to the legacy output (@Arlolra believes there are some issues with cut-and-paste of RDF-contiaining output from legacy pages to VE, and has a proposal on how to deal with it)

Taking a look at https://de.wikivoyage.org/w/api.php?action=query&meta=siteinfo&siprop=general|namespaces|namespacealiases|statistics|magicwords

A request can be made to the REST API to lint arbitrary wikitext,

If I'm reading this correctly,

The breakage is because of T134469, similar to T303705#9103106 and T275475#9094307

Similar to the discussion at T294720#8670929, we need to show that tidy would have done this migration in the presence of a bold tag, since we're trying to detect a rendering difference, post switching to remex, that could result in a visual regression.

Also, note that T173943 is a related task about filtering counts by content namespaces.

In T231161#8932572, @Sbailey wrote:

Once I get the multi-select for namespace deployed, I will look at "page quality filter" and see where that data exists in the database and if that conditional can be added to the current linter report query in a reasonable performance wise way.

A request can be made to the REST API to lint arbitrary wikitext,

> curl -X POST -H "Content-Type: application/json" -d '{"wikitext":"<div>test"}' https://www.mediawiki.org/api/rest_v1/transform/wikitext/to/lint
[{"type":"missing-end-tag","dsr":[0,9,5,0],"params":{"name":"div","inTable":false}}]

I imagine this works because of fixes in T261181 but, in any case, it no longer seems to be an issue.