This is not a Parsoid problem because https://pt.wikipedia.org/api/rest_v1/page/html/Hipotiroidismo shows that it has content as well. Tagging MCS instead.

Looks like an older verison of MediaWiki? Can you post what version it is running via Special:Version?

Fixed - https://en.wikipedia.org/w/index.php?title=Molecular_geometry&type=revision&diff=868031625&oldid=861492946
Parsoid output looks good too now - https://en.wikipedia.org/api/rest_v1/page/html/Molecular_geometry

Reducible to the following edge case:

[subbu@earth:~/work/wmf/parsoid] cat /tmp/wt
  :{|
  |foo
  |}

In T208793#4732354, @Arlolra wrote:

What you've produced is not the crash, but the reason for it. You're piping the rendered page into /dev/null, meaning it didn't crash.

When you add --wrapSections is dutifully crashes.

Cannot reproduce locally.

I get a different error locally

Cannot reproduce this locally. Can you?

[subbu@earth:~/work/wmf/parsoid] parse.js --useBatchAPI --pageName 'South_Park' --linting --oldid 865624208 < /dev/null > /dev/null
[subbu@earth:~/work/wmf/parsoid]

There are 100 helpers in Util.js and ~200 helpers in DOMUtils.js which is far too many!

In T201184#4704523, @EBernhardson wrote:

Looking over the last week of logs, these only seem to occur in cases of vandalism that create very non-standard wikitext pages. In principle, what is the desired outcome here?

• Should CirrusSearch fall back to some other tag stripping algorithm when Remex fails? Maybe php's strip_tags ?
• Should Remex be fixed to fallback from regex to something else and never fail?

Notes published @ https://www.mediawiki.org/wiki/Wikimedia_Technical_Conference/2018/Session_notes/Identifying_the_requirements_and_goals_for_the_parser

Without digging into the details, is this lintable and classifiable as 'unsupported' behavior?

In T206040#4694962, @Arlolra wrote:

But, the other major difference seems to be in the reported PEG time ... which doesn't make any sense to me. Is that faulty profiling? Total PEG time should not change whether we do sync tokenizing or async tokenizing unless this is causing some backtracking pathology to kick in.

I can look into it if you aren't already

In T206040#4694731, @Arlolra wrote:

Wrong diagnosis

It may have been true prior to T207093 / T187848 when you filed this (well, it still exceeded resources but that was suppressed giving it time to timeout).

Wrong diagnosis. The clerks page above fails because of hitting our existing resource limits.

In T206066#4678531, @cscott wrote:

Re the first question, I feel the "significance" section presupposes a particular answer (ie, that WYSIWYG editors aren't appropriate for templates, and so wikitext editing should be limited). I don't agree (T114454), but regardless, here's my attempt at rephrasing the prompt in a neutral manner:

"If products are heading toward a WYSIWYG (or micro-edit, or...) experience, does that limit the tasks we can accomplish? Should we try to narrow or broaden the abilities of our WYSIWYG (or micro-edit, or...) tools? If wikitext is a tool for a subset of editors, does that affect goals for the parser? Conversely, if WYSIWYG is intended to be a complete editing experience, what parser limitations do we need to lift?"

In T198511#4671947, @Whatamidoing-WMF wrote:

The earliest I've found at enwiki was on Saturday, 14 April 2018:

• https://en.wikipedia.org/w/index.php?title=Nightwish&diff=836341923&oldid=832800174
  
  I also found an edit on Wednesday, 11 April at enwiki that was not affected by this, so something in the deployment train during the week of April 9th is likely the trigger.
  
  @Magioladitis and @NicoV: This bug is causing ugly wikitext at all the wikis. There are probably a few hundred (but not thousands) of these problems at enwiki alone. Do you think think that the clean-up work could be automated?

@Esanders and I discussed this from a VE point of view, and Ed seems to have ideas of how to deal with the deletion case when template styles are deduplicated. We'll go ahead and implement this in Parsoid.

In T206040#4644348, @ssastry wrote:

For https://en.wikipedia.org/wiki/List_of_law_clerks_of_the_Supreme_Court_of_the_United_States, there is a lot of identical template calls. Parsoid should probably cache output of templates in case they are reused on the page. We should check how the PHP parser treats this problem. For example, if there are multiple occurrences of {{#time:U|now}} on a page, will they all report the same time? Or, will this only happen if that is wrapped in a template?

90 day codfw traffic and 90 day eqiad traffic graphs.

In T187142#4667398, @Tgr wrote:

Note that deduplication should only happen after Cite did its own duplication checking of <ref> tags. In the PHP parser that caused T205803: Duplicate reference name errors in English Wikipedia caused by MediaWiki templatestyle handling? (although there the deduplication happens late so the exact cause was different).

In T206527#4664991, @bearND wrote:

This causes the Parsoid HTML to be bloated and results in clients taking longer to download and parse the payload. I cast my vote for Parsoid fixing T187142.

Still, I agree that the clients trying to parse references need to be updated to handle <style> tags but also <link> tags as well, assuming Parsoid will fix that in the future.

In T206527#4659479, @Dbrant wrote:

The problem seems to be that each reference in the list of References now includes a <style> tag which contains a large block of inline styles, which seem to be identical from one reference to the next. This <style> tag doesn't seem to be present in the Web version of the article. Do we know its origin and/or purpose?

I don't see a problem currently @ https://en.wikipedia.org/api/rest_v1/page/html/Nadia_Murad .. maybe some template was temporarily incorrectly edited? Can you confirm if this is still a problem?

@Andrew Everything looks good so far. I had to tweak some configs (because some of the dir paths are slightly different) but otherwise, all looks good to me. I've updated the DNS in horizon to point to parsing-qa-01.

In T184755#4656385, @matmarex wrote:

Update:

• All the repos have been mirrored on parsing-qa-01
• All the dbs have been mirrored on parsing-qa-01
• I installed / built required packages
• I set up the pngs directory for dumping the visual diff images
• I set up all services and mirrored their service files from promethium
• I set up nginx, and various setup and config files
• I mirrored /etc/hosts (with the existing comment # SSS: Temporary hack while we wait for T132216 to be resolved)
• I started a new run of the tidy vs remex visual diffing code there.

In T198511#4649642, @rakekniven wrote:

@ssastry Any update regarding release of Parsoid? Our wiki is still losing working links.
In the meantime I upgrade our MW instance to v1.13.1 and Parsoid is still 0.9.0

Can somebody tell me the manual steps to get it working again. Maybe @DLynch ?
I really do not like to wait until Parsoid has its pieces together.

Any help is really appreciated. Thank you.