@elukey it woooorks! thank you :D

@Nirmos we backported that patch to wmf.4, so the fix should be available on all wikis as of a few minutes ago.

1. Risky Patch! 🚂🔥

It's unclear what the current candidate for this week deployment is, because we have T411238 and T411212 in flight.

Ack, that was my understanding between idoptions and idhash, I was just making sure I wasn't missing something more in there, thanks for confirming.

As far as I can tell, these are all on parsoidtest1001, and are the result of a run of RT-Testing with parsoid 0.23.0-a7 on a wmf.3 (and those are incompatible). Closing this unless there's something I missed (in which case please reopen!)
In any case parsoid 0.23.0-a7 on wmf.4 should not throw any of these, and since group2 is in wmf4 it should be all good.

As far as I can tell, these are all on parsoidtest1001, and are the result of a run of RT-Testing with parsoid 0.23.0-a7 on a wmf.3 (and those are incompatible). Closing this unless there's something I missed (in which case please reopen!)
In any case parsoid 0.23.0-a7 on wmf.4 should not throw any of these, and since group2 is in wmf4 it should be all good.

@Ladsgroup when in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1079677 you're talking about "all entries for the same page end up in the same database table in the same cluster", I'm assuming that this only applies to entries for a given ParserCache instance, right?
If I read the current code correctly, already entries for "regular parser cache" and "parsoid parser cache" would probably not end up in the same shard, since the name of the cache is in the part of the key used to determine the shard.
And, from a conceptual point of view, I can see why we'd want "entries of a given cache for a given page want to go to the same shard", but differently named caches should normally be independent and don't have that constraint, even if they're caching content that relate to the same page - because in that case, depooling one shard will only hit a set of entries that should be independent from the other possible set of entries in other caches for that same page.

Whooops. Seems we have forgotten a couple of options for ParserOptions, sorry about that. I'll fix that; it may be worth backporting on the train because it has some potential to be noisy on larger groups. But it shouldn't indeed affect the rendered result.

Aha, that does explain why it didn't seem to be a problem in practice (which felt either very lucky or of less consequences than I believed) - it used to be, but Before My Time™ :D

In T410923#11403118, @Krinkle wrote:

@ihurbain I don't know if this is relevant to your problem, but in case it helps with this or T348255:

ParserOutput is re-used in memory in the same request, but also written to ParserCache.

I don't just mean the synchronous write to ParserCache during retrieval for cache misses (these would not affect you as it is saved before returning to you), but also the asynchronous writes.

Like so:

• Request 1: Initial cache miss
  • [mid-request] ParserCache calls MultiWriteBag::get and misses both memc and mysql, we parse, we call MultiWriteBag::set which writes to memc and schedules deferred write to mysql, and we return to caller.
  • [mid-request] Any modifications here may pollute mysql.
  • [post-send] DeferredUpdate callback writes the by-ref object to mysql.
• Request 2: Cache hit on memc
  • [mid-request] ParserCache calls MultiWriteBag::get and hits on memc, and we return to caller. Nothing else.
• Request 3: Cache hit on mysql
  • [mid-request] ParserCache calls MultiWriteBag::get and misses on memc but hits on mysql and schedules deferred backfill, and we return to caller.
  • [mid-request] Any modifications here may pollute memcached.
  • [post-send] DeferredUpdate callback writes the by-ref object to memc.

1. Risky Patch! 🚂🔥

In T410693#11401595, @cscott wrote:

Oh, then not actually related to T348722: Lint indicators and couple other extensions for using {{{..}}} in extension body when using <tag>..</tag> syntax?

Quick investigation: it seems that the Kartographer style sheet is not loaded on the Parsoid page. At a guess, https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Kartographer/+/refs/heads/master/includes/Tag/ParsoidDomProcessor.php#50 is probably the culprit - we're looking at the page content, but we probably haven't included the indicators to the page yet, so it won't find it, and it won't load it.

Same symptom, different cause a priori - looking at the log, this is most probably T371617.

The issue comes from the fact that the legacy parser transforms the TOC numbering data before inserting it in the TOC to match the target language, and Parsoid does not.
The good news is that it's not something that got recently introduced in the DOM TOC patch as I initially thought.
The bad news is that a/ it's been a problem for a while and we only see it now (annoying, but thanks for reporting!!) b/ it may be a vaguely more annoying fix than I hoped because the OutputTransform will need to distinguish between these two cases and apply number localization or not.

I checked, this has no user-facing impact, train can go forward with (hopefully limited) logspam as the only consequence, for which I have a patch (let me commit that :) )

We explicitely exclude HardenNFC from this task as this is a text-only-pass that happens at the end of the pipeline, and makes no sense to convert to DOM.