I've looked into that yesterday (and put my notes in T222419#10058673); I am not *convinced* that it requires the wikitext to be invalid for it to trigger. The PEG parser might backtrack on valid-wikitext-that's-just-ambiguous-enough, without the wikitext itself being entirely at fault. I think.

I *think* that the issue discussed on https://en.wikivoyage.org/w/index.php?title=Wikivoyage%3ATravellers%27_pub#Listing_editor_issue_in_Emeryville and also triggered by trying to do "Edit source" on any section edit link apart from the first 3 on https://en.wikivoyage.org/w/index.php?title=Emeryville&oldid=4921380 is also a matter of "PEG parser tries to do thing, backtracks, and doesn't reset the ID".

I agree it's probably time to retire these wrappers - they have posed significant problems already, whose solutions involved adding more cruft (I can say that, I did that :D ), and the issues you're pointing out are absolutely valid. It felt easier to go that route at the time, but it seems clear by now that feeling easier came with a healthy does of being overly simplistic :)

This is actually an issue with the usage of Collapsible Elements, which uses the same toggle to toggle two elements at the same time with the same ID, which is the circumstance under which Parsoid will actually overwrite the element ID. We suggested an edit on the template in https://en.wikivoyage.org/wiki/Wikivoyage:Travellers%27_pub#switch_to_interactive_map_does_not_work.

The issue is that the regionlist template uses id html attributes to have the "interactive" map open as the "static" one gets toggled off https://en.wikivoyage.org/w/index.php?title=Template:Regionlist&diff=prev&oldid=4073000.

Things of note on group2:

• the logs have a significant (~12000) amount of log messages over a period of 30 minutes or so with "database servers in clusterXX are overloaded, circuit breaking have been activated" (where XX is 26,27, 28, 29). Plausibly, but not entirely sure, related to T370304.
• the number & rate of parsercache hits has increased, correlating with the introduction of pc2017 (T369658)

Possibly related - I was complaining yesterday about Gerrit not showing me unresolved comments on a previous version of a file. So I tested a couple of things on /test/gerrit-ping, as suggested by @hashar.

Some larger than expected number of 500 errors, but due to a couple of clusters being offline during the run.

Seems to be an issue with the Maps extension: https://translatewiki.net/wiki/User:Balise42/sandbox shows the same behavior with a single line. It probably needs to be adjusted for Parsoid usage.

Mmmh. Easier, probably: exclude all whitespace unless it's a single \n. This way we avoid touching lists & tables in "less-corner-case" cases, and it feels less hacky/easier to justify. (and it seems to be passing parserTests as well.)

I played around a bit with that thing, and I'm arriving at a proposal looking like a variation of \n\n (PS2 on https://gerrit.wikimedia.org/r/c/mediawiki/libs/RemexHtml/+/1052779).

There, I spent a significant amount of time hunting down where the discrepancy comes from.

As a side note: I was not ENTIRELY sure that the hewikivoyage button was triggered by a __NEWSECTIONLINK__, but I finally managed to confirm that it was indeed the case (well, its localized equivalent).

It seems *plausible* that Parsoid output loses/does not fill in the right information when the page asks for the insertion of the Add topic button (with __NEWSECTIONLINK__).

At the point it enters remex, it looks like

On the other hand, legacy fixes that in the output, and Parsoid does weird stuff:

Good point - I had missed that. Let me check other hewikivoyage pages to see if it's a more general thing.

Also probably:

Probably the same issue on
https://en.wikivoyage.org/w/index.php?title=Madang-Morobe&useparsoid=0
https://en.wikivoyage.org/w/index.php?title=Madang-Morobe&useparsoid=1

We had a bit of a hiccup on the merge of this patch (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1037576); I'll make sure it rides this week's train - should be fixed on all wikis by the end of the week. Thanks for raising this!

RT-testing of a78e700 is clear (logs & regression-testing script).

@cscott probably, we would probably want to refresh Subbu's patch above https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/837147