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.
Wed, Jun 23
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
Tue, Jun 22
Desktop Parsoid render does it right as well:
But Parsoid Mobile does not:
Mon, Jun 21
Here's an isolated case,
This can be isolated to,
Mon, Jun 14
At least that's what I think is going on.
Fri, Jun 11
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.
Do you think the length of the page could explain the error JKlamo is experiencing?
Thu, Jun 10
Querying Parsoid directly yields,
php bin/parse.php --domain br.wikisource.org --pageName "Pajenn:Troude ha Milin - Imitation Jezuz-Krist, 1862.djvu/386" < /dev/null [warn/dsr/inconsistent] DSR inconsistency: cs/s mismatch for node: i s:131 ; cs:135 Wikimedia\Assert\InvariantException from line 224 of /services/parsoid/vendor/wikimedia/assert/src/Assert.php: Invariant failed: Bad UTF-8 at end of string (3 byte sequence) #0 /services/parsoid/src/Utils/PHPUtils.php(218): Wikimedia\Assert\Assert::invariant(false, 'Bad UTF-8 at en...') #1 /services/parsoid/src/Wt2Html/PP/Processors/WrapTemplates.php(963): Wikimedia\Parsoid\Utils\PHPUtils::safeSubstr('<noinclude><pag...', 126, 42) ...
Wed, Jun 9
It seems to happen often enough to where that doesn't seem like a great explanation though.
Tue, Jun 8
@Pchelolo What's the status of this?
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.
Sat, Jun 5
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
Fri, Jun 4
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:
Thu, Jun 3
I'll try and get it reviewed now so it can ship next week.
Wed, Jun 2
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
Tue, Jun 1
Thu, May 27
May 26 2021
May 25 2021
Note that there's also the other entity encoding <b>·</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",?
May 24 2021
Syntaxhighlight doesn't consider its content as wikitext so the following doesn't work,
May 14 2021
May 10 2021
May 8 2021
Looks like these are pages running up against size limits which differ between Parsoid and the legacy parser,
May 7 2021
Okay so it sounds like in future content-media might merge into content-thumbnails e.g. these rules are additional?
May 6 2021
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,
May 5 2021
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.