Also, keep in mind that the timeout in $wgVirtualRestConfig is meaningless and should either be removed as distracting or fixed in MediaWiki to do what it's supposed to do and override $wgHTTPTimeout,

Also consider T279825#7174049

Please let us know if you would value our help with QA.

There's some good information here, so thank you to the participants, but the two types already have individual tasks, as mentioned in T282322#7072938

Gerrit is leading me to assume you all (Parsing) have code review covered for this.

With that deployed, this seems to be resolved for OfficeWiki

Desktop Parsoid render does it right as well:
...
But Parsoid Mobile does not:

Here's an isolated case,

This can be isolated to,

Has the parsoid lack of support for language variants been fixed? cc/ @Arlolra and @cscott

At least that's what I think is going on.

Well, the above conclusion was that the legacy parser doesn't return an http error when hitting complexity limits, it degrades the response by leaving some wikitext syntax unparsed.

See T279825#7151307

Do you think the length of the page could explain the error JKlamo is experiencing?

In T173911#3590198, @Arlolra wrote:

See some discussion in T58381 and https://gerrit.wikimedia.org/r/#/c/232313/

Querying Parsoid directly yields,

It seems to happen often enough to where that doesn't seem like a great explanation though.

In T280450#7083576, @ssastry wrote:

The reason I filed it then (and it is being filed repeatedly again) is that this was a change in behavior - this was not being logged before at all. So, did something change in core around request timeouts? Or did something change in logging?

In T280381#7140034, @Kelson wrote:

I'm not 100% clear what is the next step here, should we just wait the next Parsoid PROD rollout and check again?

@Pchelolo What's the status of this?

In T284570#7142785, @Kelson wrote:

Then, might be a duplicate of https://phabricator.wikimedia.org/T217540 ?

T284570 is a similar case where a file was moved from enwiki to commons and changeprop did not request to rerender the pages including it.

So, it existed on enwiki and Parsoid rendered the page and cached the result. And then got imported and deleted from enwiki.

From https://commons.wikimedia.org/w/index.php?title=File:Fisher_iris_versicolor_sepalwidth.png&oldid=555722523

In T284570#7142615, @cscott wrote:

This is the instantcommons fallback, since the image is not present on enwiki it should be grabbed from commons. I was pretty certain that instantcommons works in Parsoid, I wonder what's going on. @Arlolra any ideas?

Are you sure? The ToC seems to be here https://bn.wikisource.org/api/rest_v1/page/html/%E0%A6%85%E0%A6%AC%E0%A6%B0%E0%A7%8B%E0%A6%A7_%E0%A6%AC%E0%A6%BE%E0%A6%B8%E0%A6%BF%E0%A6%A8%E0%A7%80#mwDA

Some example pages are listed in T280381#7135508

In an attempt to help you diagnose the problem (or verify the patch works fine), here is a list of other URLS suffering for the same symptom:

I'll try and get it reviewed now so it can ship next week.

Parsoid has some ability in WikitextEscapeHandlers::hasWikitextTokens and the whole ConstrainedText thing to detect if text we're about to serialize needs escaping because it'll combine with previous characters to form valid syntax / tokens, as @matmarex says. But, in practice, that probably works more on a line than at a page level at the moment.

I am not clear on a good reason why mediawiki.skinning.interface should ever be loaded. I'm hoping that's a bug...

I'm not sure what is loading mediawiki.skinning.interface... but that's not done by core.

Looks like I fixed it with this edit

In T280381#7114298, @Kelson wrote:

@Arlolra Any problem with your patch? It seems stuck since 2 weeks.

Note that there's also the other entity encoding <b>&middot;</b>

We could remove Parsoid from there if you'd like, with the expectation that whenever a 4.x comes out, a human will tag Parsoid in the task that LibUp files.

@Legoktm Is this because LibUp doesn't know what to do with "composer/semver": "^1.7.2|^3.2.4",?

It's reproducible with,
https://ar.wikipedia.org/w/index.php?title=%D8%A8%D9%8A%D9%86%D9%8A_%D8%AF%D8%B1%D9%8A%D8%AF%D9%81%D9%88%D9%84_(%D9%85%D8%B3%D9%84%D8%B3%D9%84)&oldid=53445436&veaction=edit

Syntaxhighlight doesn't consider its content as wikitext so the following doesn't work,

In T278560#7086867, @Jdlrobson wrote:

^ @Arlolra for your consideration (no urgency from my side)

Looks like these are pages running up against size limits which differ between Parsoid and the legacy parser,

Okay so it sounds like in future content-media might merge into content-thumbnails e.g. these rules are additional?

When there are no parameters would be possible converting it to this instead?

The comment from User:JAn can't be replied to,

It looks like this is the edit that caused the problem,
https://cs.wikipedia.org/w/index.php?title=%C5%A0ablona%3A%C3%9A%C4%8Dastn%C3%ADk_WikiProjektu_Televize&type=revision&diff=18664158&oldid=16443661

For completeness, I'll mention that Parsoid/JS is no longer in production at WMF. For the released package, kad is not a default backend for service runner's rate limiter, it would have had to have been explicitly enabled by someone running it. Further, the keys on which the effected package (merge) was used in kad don't seem to be user controlled data.