As the above snippet shows, $a becomes a regular array and when json-encoded, the encoding uses regular array syntax. This is likely a narrow edge case but something worth investigation. This is likely to be only fixed with typed token properties.

This is triggered by a wikitext error in a table row. | ... ||0 | 0. That last 0| should have been ||0.
But, this gives us an easy test case:

[subbu@earth:~/work/wmf/parsoid] echo -e "{|\n|1||0|0\n|}" | node bin/parse.js --body_only
<table data-parsoid='{"dsr":[0,13,2,2]}'>
<tbody data-parsoid='{"dsr":[3,11,0,0]}'><tr data-parsoid='{"autoInsertedStart":true,"dsr":[3,10,0,0]}'><td data-parsoid='{"dsr":[3,5,1,0]}'>1</td><td data-parsoid='{"stx":"row","a":{"0":null},"sa":{"0":""},"dsr":[5,10,4,0]}'>0</td></tr>
</tbody></table>

@Ryasmeen: the 'new page creation' bug is now resolved and new code is on beta cluster as of y'day. Let us know if you find any other bugs. Or, a confirmation that you could run all your QA tests successfully! Thanks!

We went with option #1 here. We don't expect perf. issues but given our instrumentation, we'll know if something is off here and can revisit this.

Language team: As of yesterday, new code is on both beta cluster and production that can handle new pages. You may have already inferred it by the resolution of the blocking subtask, but just in case you hadn't, this is FYI about it.

Thanks @eprodromou and @tstarling for the attention and pointers.

Unsurprisingly, Parsoid/PHP once again matches core rendering here and Parsoid/JS is the one that differs.

Removed 4 duplicate comments that actually went through while Phab was unresponsive.

Looking at the output of https://uk.wikipedia.org/wiki/Hitman:_Contracts, Parsoid/PHP matches the current rendering. Parsoid/JS seems to be at fault here.

In T237103#5665934, @ssastry wrote:

I see a bunch of similar errors in the parsoid-tests logstash board: https://logstash.wikimedia.org/app/kibana#/dashboard/parsoid-tests?_g=h@97fe121&_a=h@d8af28b

I see a bunch of similar errors in the parsoid-tests logstash board: https://logstash.wikimedia.org/app/kibana#/dashboard/parsoid-tests?_g=h@97fe121&_a=h@d8af28b

In T229077#5659801, @JoeWalsh wrote:

Hi @ssastry -
Two potential issues I noticed when running the tests with the header to request the php output:

1. Previously scheme-less urls for videos now have a scheme. For example, on enwiki Hummingbird/810247947 the URLs for videos had their prefixes change from //upload.wikimedia.org/ to https://upload.wikimedia.org/
2. The title in the href of the link tag with rel="dc:isVersionOf now uses spaces instead of underscores. For example, on enwiki User:BSitzmann_(WMF)/MCS/Test/Frankenstein/778666613 the href changed from //en.wikipedia.org/wiki/User%3ABSitzmann_(WMF)/MCS/Test/Frankenstein to //en.wikipedia.org/wiki/User%3ABSitzmann%20(WMF)/MCS/Test/Frankenstein

This fix is now on beta and I verified it works by creating https://en.wikipedia.beta.wmflabs.org/wiki/T238161_test

In T234549#5664959, @Arlolra wrote:

I'd like to keep the clarity of SelserData, that accessing the page frame while serializing should throw, unless we're doing selser.

I think Parsoid/PHP is better code here since it handles titles consistently but let me check in with others to see what ought to be canonical title output here.

In T229077#5660700, @ssastry wrote:

Will look into this.

Got it. Looks like Parsoid/PHP normalizes titles whereas Parsoid/JS emits it as given.

One quick obvious thought. Maybe a "data-ve-multiline-reply-hack" attribute to the list-item span which is similar to your data-parsoid="": hack, but something which is less-hacky (since we don't want editors dealing with data-parsoid). We can remove support for this attribute once the multi-line list syntax lands. The "-hack" serves as a reminder to us all not to keep it around.

In T229077#5659801, @JoeWalsh wrote:

Hi @ssastry -
Two potential issues I noticed when running the tests with the header to request the php output:

In T229074#5658979, @ppelberg wrote:

In T229074#5657514, @ssastry wrote:

Editing team: We want to catch problems sooner than later, so checking in about updates on how testing is going here.

We started testing today, with plans to finish on Thursday.

Hi Product Infra Team: We want to catch problems sooner than later, so checking in about updates on how testing is going here. Anything that you need from us? Or, is everything looking good on your end?

So, in logstash, I see the following warnings emitted by Parsoid/JS: Batch request The value passed for "batch" contains invalid or non-normalized data. Textual data should be valid, NFC-normalized Unicode without C0 control characters other than HT (\t), LF (\n), and CR (\r). for the page frwiki:Ṳ́, which then leads to this warning emtited by the AddRedLinks pass: We should have data for the title: Ś.

Language Team: We want to catch problems sooner than later, so checking in about updates on how testing is going here. Anything that you need from us? Or, is everything looking good on your end?

Editing team: We want to catch problems sooner than later, so checking in about updates on how testing is going here. Anything that you need from us? Or, is everything looking good except for that one bug that @matmarax found ( T237666: Parsoid/PHP fails for transforms for new pages with slashes in the title ) ?

In T234280#5645999, @matmarex wrote:

I think I see the exact problem here. In the Parsoid HTML (https://www.mediawiki.org/api/rest_v1/page/html/Developer_Advocacy), there are two elements with about="#mwt67" and different data-mw:
...
They are in different sections, so while weird, this doesn't immediately break things. But after unwrapping the sections (ve.unwrapParsoidSections(document.body, undefined)), these two elements become siblings, so the two about-groups get merged into one, and the data-mw from the second element is lost.
Is this a bug in Parsoid?

Likely caused by this: T231569#5502186 .. to resolve port conflicts between Parsoid/PHP and Parsoid/JS in the beta cluster. @Catrope found that Parsoid/JS is listening on 8001, not 8000 as Flow is configured.