I am waving hands here, but I wonder if this is a symptom of OOM / timeout and something not being cleaned up properly on the server, but not sure how / why a new request would be sent to the same process.

I don't think we'll ever get to this and all this is a bit of water under the bridge. So, I am simply going to decline this.

Interestingly enough, as part of work to run parser tests in Parsoid integrated mode, I was investigating related failures and this isolated bug made it easy for me to fix those. :)

Yes, that took me a while to spot but ([https://www.delcampe.net/static/img_large/auction/001/179/750/079_001.jpg image) is missing a closing ] char which causes wikilinks later in the line to get swallowed into it which triggers this bug in a wikilink-in-extlink lint error scenario.

Will likely be deployed on next week's train.

So, it is okay to shut down these VMs by end-June. But, if our quota is expanded before end-June, I may look into booting these up again if I have spare time from other tasks.

Horizon says I don't have quota to launch new VMs.

Can be easily reproduced with this snippet:

[subbu@earth:~/work/wmf/parsoid] cat /tmp/wt
* [http://google.com [[Foo]]]. bar ''baz''

This looks like probably the same reason as in T310220#7990302

There is a wikilink nested inside an extlink. And, all subsequent markup in that DOM level are marked misnested which seems like possibly a buggy outcome of my fix for T307412: Link-in-link wikitext error resulted in duplicated content in a reply tool edit. Will take a look.

At first glance, (a) these are normalizations in a dom that is considered modified. (b) It is marked modified because an old comment is now nested inside a newly inserted comment and so Parsoid probably treats the whole subtree as modified.

Will take care of it this week.

Fair, but, there may be some tweaks to Sanitizer code nevertheless since we might end up changing the representation here. The general problem is that we don't have a good representation when more than the attribute is templated (or at least that is how our tokenizer / attribute expander sees it).

https://cy.wikipedia.org/w/index.php?title=Nodyn%3APigion%2FWythnos_34&type=revision&diff=11055970&oldid=2243475 is another one I fixed.

I think so. Parsoid/JS is no longer supported and won't get security releases either. If anyone on the team has any concerns, they will leave their comments here.

Whitespace handling in wikitext is generally very messy. @Arlolra and @cscott both wondering why we trim argument values at all in any context So, I'm going to dump a WIP patch for now exploring that.

Crasher can easily be duplicated via echo "{{DEFAULTSORTKEY:{{1x|foo}}}}" | php bin/parse.php

I was about to type this --> I am not sure what we can do here realisticallly. If a template is marked as inline-formatted, the newlines will be stripped. Without more fine-grained types about parameters (a type that says: "this parameter is a wikitext construct that needs a leading newline"), it is hard to do much there.

In T309681#7973796, @Dbrant wrote:

We use the VisualEditor API to get the text of the edit notices, and I believe VisualEditor in turn uses Parsoid to parse the notices (and TemplateStyles isn't compatible with Parsoid yet, if I understand correctly). Therefore tagging Parsoid.

Here is an API call to visualeditor that will produce the same results (under the permissions-error notice):
https://en.wikipedia.org/w/api.php?format=json&formatversion=2&errorformat=html&action=visualeditor&paction=metadata&page=Barack_Obama

TemplateStyles is compatible with Parsoid. This may be an edge case / bug. We will have to take a look.

/w/rest.php/en.wikipedia.org/v3/transform/wikitext/to/lint/Talk%3ASiln%C3%A1n/1090134717 is the other page.