@cscott and I chatted a bit about this yesterday.

https://fr.wikipedia.org/w/index.php?title=Humour&oldid=38819316&useparsoid=1 renders just fine?

A similar edge issue is seen on this tawiki page: (legacy, parsoid).

https://logstash.wikimedia.org/app/discover#/doc/logstash-*/logstash-deploy-1-7.0.0-1-2025.11.22?id=NcL0q5oB8DimCzrVbCsY is another set of logs which has an url associated with it.

This diff no longer exists. Fixed with one of the patches that are now in production.

These are likely from parsoidtest1001 where I am doing perf benchmarking by checking out old versions of Parsoid and so these are all emitted from there (I see them on the console) because parsoid old version and core new version aren't always compatible. The stack trace also shows these are from the maintenance script. So, you can ignore them -- ignore any traces from parsoidtest1001 in general. Surprised they aren't filtered already.

This panel shows an increase in traffic to the wikifeeds_featured endpoint as well as wikifeeds_onthisday endpoints. And this panel shows an increase in upstream request timeout for those two endpoints.

This panel shows a spike in RX traffic corresponding to the increase in latencies, etc.

Can reproduce it with a simple snippet:

╰─➤  echo "{{#|a|b=c}}" | php bin/parse.php                                                                                                                                                                  148 ↵
Wikimedia\Assert\InvariantException from line 231 of /home/subbu/work/wmf/parsoid/vendor/wikimedia/assert/src/Assert.php: Invariant failed: Parameter 1 should be positional!
#0 /home/subbu/work/wmf/parsoid/src/NodeData/TemplateInfo.php(127): Wikimedia\Assert\Assert::invariant()
...

This wikitext is the source --> {{#|تاريخ الميلاد والعمر|السنة=1956|الشهر=5}}. I am certain it is the {{# which is confusing Parsoid which is treating it as some parser function instead of an invalid transclusion.

This looks new to this train.

In T409187#11343202, @Izno wrote:

I see a couple gadgets on he and hu wiki also that seem to care about the property.

guwiki also reported this on mw:Parsoid:Feedback.

Changing status to blocked until we resolve what additional things we need to do here. For now, as noted above, our inclination is to wait it out for Izno's fixes to land.

In T378906#11286730, @Izno wrote:

I've added amboxes to the same page. (They are tables currently and probably a good chunk of the fleet, but I am incidentally working on making them divs. Which still doesn't fix the whole fleet.)

I've split up the ExtractBody pass into two and moved the relative attribute expansion code to a DOM pass further down in the pipeline. After this change, the ExtractBody pass itself is trivial and can stay a text transform.

The huwiktionary pages now render "identically". We will run visual diff on this wiki soon and see what are the remaining blockers to deploying read views on this wiki.

#1 & #2 are fixed by the first two patches. #3 is mostly fixed by the above patches, but not entirely. To be investigated.

Of the four cases, the first three are relatively easy to fix. The fourth one might end up being a wontfix -- to be investigated more.

I'll get back on this once we've worked through some details.

Ya .. that is my sense too that Parsoid's behavior is the right one, but filed it for the record.

Or a span.mw-empty-elt

Ah, I had the fix narrowly target divs for navboxes. Can't do the same for tables because of fostering reasons. Short of hoisting deeper -- into the "last" <td> -- which feels very ugly, I don't have a good Parsoid-side solution at this point.

Oh, there is no problem with having the </includeonly> or noinclude on the same line. It is the " " that is the problem. Do you need it? If not, it can be on the same line. Can you give me an example of a page with the ambox page (with a rendering diff, ideally) that I can look at?

https://www.mediawiki.org/w/index.php?title=User:Izno/Sandbox/Category_holder&diff=prev&oldid=7945477 fixes it for example. I'm going to close this as resolved. Please leave a comment if you disagree. Since the patch is kind of a mild hack, we mostly want to keep it as narrow as possible.

@Izno I am inclined to close this task as resolved even though your specific example is not fixed. There is a simple wikitext fix solution available which is the change the to a \n and the patch we deployed will kick in. The patch already fixes all the ugly inter-navbox spacing on the test pages and your example looks like an edge case which has a relatively easy fix.

The inter-navbox spacing issues on enwiki are fixed, but the example Izno provided above isn't because my patch narrowly targeted only newline wrapping instead of whitespace wrapping (and Izno's example has </div> [[Category:..]] So, the separator is a space char, not a newline like the common usage on enwiki.

Looks like I hastily tagged this task with my patch which narrowly targets navbox extremities and this task is different (even if the issue is similar) where the span wrappers are in the middle of the content - between a <div> and <ul>

T384060: enwiktionary: Parsoid's output includes self-links for fragment links unlike legacy output is the issue on enwiktionary that fails because of using this same hack. We haven't yet figured out how to solve this issue.

We fixed this sometime in the last 12 months.

Confirmed that the patch fixes the problem.

You got it right. But, there are lots of pages on wikis where they are getting lists where they didn't necessary intend to get lists! So, this lint is to warn them where there is a single "list item" but where the list item is unintentional. In almost all cases <ref>*foo</ref> OR <ref>***foo</ref> (seen on a wiki where every single ref had this and I edited the page to remove those) are probably not meant to be lists.

This snippet: <ref>foo {{start box}}</ref> is enough to reproduce this on zhwiki. Clearly markup error because why would you start a table and leave it hanging inside a ref tag? But, we shouldn't crash on that snippet. Will fix tomorrow.

Yes, that helps. I was looking in the structured fields, and never paid attention to the message. :) https://zh.wikipedia.org/wiki/%E7%A8%8B%E7%A7%80%E6%B0%91?useparsoid=1 crashes and I can debug that.