Some questions: I suppose that is enforced by editors writing categories in the desired order at the end of the article? But, if a template in the middle of the article (or an infobox) adds a category, I imagine it shows up wherever it showed up in text, right? So, to Scott's question, it is not quite a set, but it an ordered list with the output being generate in textual order?

Ya, I don't think this is a generic hlist issue -- Parsoid's HTML for wikitext lists already include the newline (the newline found in source wikitext) -- so I am not sure the hlist issue affects anything else. If it were, we would have heard this long back because hlist is used on lots of wikis.

https://en.wikipedia.org/wiki/Special:LintErrors/fostered-transparent now exists.

In T372574#10067385, @ABreault-WMF wrote:

@ssastry Maybe you can follow up restoring the cluster graphs from T371126#10067372

The extra noise has disappeared. The actual table reparse issues will be handled separately.

Looks like this is very specific to Cite references output (from the navbox) and the CSS expects a newline between the "</li><li>".

Looks fixed to me! \o/

Ooops merged the wrong way.

You are right indeed - that looks fixed with this morning's production rollout to group1 wikis!

I guess this will get fixed tomorrow when the train rolls out!

See the very first section ( Latest comment: 10 months ago1 comment1 person in discussion ) ... you can also see the diff in the TOC on the left (which is how I first noticed it).

Indeed. This is almost certainly a wontfix. For Parsoid, they should probably disable the nowrap CSS rule.

This is probably fixed - someone should verify and close it.

I am going to reopen this because of the discussion on the dupe task -- the patch that caused us to decline it does a slightly different thing (it looks at start of template) than what is needed (look at end of template). It is possible we arrive at the same result and decline it, but worth investigating a bit by starting off of Arlo's patch.

But, looks like I didn't look carefully when I looked at the gerrit patch. The phab task is indeed a duplicate, but the patch fixes the start-meta interruption (according to the commit message) vs the end-meta interruption that the phab task documents.

Not sure ... This test case is the other edge cases corresponding to the end-meta which you document in that commit message: "Similarly, this should be true for template end metas but there a newline might escape out of the template causing a dirty diff"

That patch fixes the issue.

Aha .. digging deeper, we aren't so stupid after all :slightly_smiling_face: .. the parser pipeline factory already has the attribute expander run after template expansion to avoid this kind of incorrect eager processing. So, this only happens for template tokens where the template target itself is templated (as in this example #ifeq:{{..}}) ... and so, it does need to expand that first attribute to know what the template target is. So, that logic should not be over-eager and only expand the first attribute, not all attributes, as is happening.

I think I know what is going on. So, for all tokens, attributes are processed to expand them. That seems like it might not be a problem, but that effectively means that Parsoid is eagerly processing parser-function args. That would work better if we had a Parsoid-aware implementation of parser functions (the one in Parsoid is incomplete and only there for parser test processing). Such an implementation would handle the lazy processing properly.

I can produce this bug locally -- looks like Parsoid may be doing some eager evaluation of the parser function args which causes it to add the page to the redirect category even when that part of the #ifeq would not get executed.

Ah, looks like the issue is more about <includonly>foo<includeonly>bar</includeonly>baz<noinclude>xyz</noinclude> as seen on this page. Looks like with legacy output, it matches the </includeonly> with the outer <includeonly> whereas Parsoid seems to match it with the inner <includeonly>.

There is an unclosed <includeonly> tag on the page which is causing this problem - the wikitext needs to be fixed. Looks like legacy parser resets some state (maybe when it encounters a <noinclude>). We could see if we want to institute some of that error correction in Parsoid, but this is not a blocker for deploy. We should probably fix up the page and be done with it.

Still looking but this may be an edge case because of script / syntax error on the page which prevents the "{{Documentation}}" string from getting tokenized properly in the PEG which then causes it not to be displayed.

Ran rt-testing 4 times this week and ran the regression script comparing 2bf44add and ba088428 and the results are clean - so, vendor updates are good to go on Monday.

Digging into the exception traces a bit more, it looks like these 4 lines account for pretty much every exception (except 7):

• "Separators.php(899)"
• "Separators.php(902)"
• "Separators.php(907)"
• "Separators.php(642)"

But, I am having a hard time reproducing this with some random edits on some of the pages in the logs. Need to figure out a different strategy and/or dump more logs since this is clearly user-activity triggered (edits).

About 9150 entries in the last 2 weeks ... about 1 every 2 minutes which is higher than I would like. I am not convinced this is actually bad UTF in revisions. This is across a number of different wikis (jawiki contributing almost 45% of the errors).

This snippet below is sufficient to reproduce the id-assignment issue:

=S1=
[[Foo|Bar],]

Just recording for debugging purposes since this is not reproducible on the current version of the page, if you 'view source' on https://en.wikivoyage.org/w/index.php?title=Emeryville&oldid=4921380 , you can see the bad section ids on the section wrapper tags.

RT-testing regression script shows no regressions.