Note: there's a (very) significant chance that the observed daily purge on flaggedrevs is T416616 - so, not FlaggedRevs-related.

Scott started rt-testing on 57396f78 and it's good to go; I believe 4eedc6aa is safe to stuff on top of it on Monday if we want to and if no other rt-testing is run over the week-end.

Leaving this one open because I don't know what's the exact status of T421359 that got triggered on this train.

Parsoid FlaggedRevs postprocessing cache has been running for a week, so let's consider this resolved.

This is essentially T345568.
Note that both https://fr.wikisource.org/wiki/Le_Jugement_de_Satan_(Viennet)?useparsoid=1 and https://en.wiktionary.org/wiki/Wiktionary:Sandbox?oldid=88313457&useparsoid=1 do work correctly - the issue is that we're not fixing URLs in these cases to handle the base URL correctly. Not ideal. (And the reason for that is that these elements are kind of out-of-band for the main parse, and so they're never processed by the post-processing... which among others handles the relative-to-absolute URLs).

As far as I can tell, this is fixed for both CheckUser and VE, so closing.

Oops, sorry for hijacking the thread, then (want me to put that somewhere else?)

The whole thing, bar a couple of redacted elements (for another image on officewiki):

I can see this behaviour on the (internal) OfficeWiki, on the Contact List, on Firefox 148.0 on Linux (Ubuntu snap packaging), from a connection with the Init7 internet provider in Switzerland.

There seems to be some amount of temporal causality with a more general pattern of a drop in hit rates for ParserCache - see https://grafana.wikimedia.org/goto/SBEpS9NDR?orgId=1 for details, and the attached graph for the TL;DR of what I mean:

I've done a quick Excimer run on a post-purge legacy parse (since parts of DT are cached on these parses) and on a Parsoid parse (where they're not yet).

We have deployed the fix a few minutes ago.

@brennen from our perspective, we expect some logspam, hopefully limited, but no other consequence (hence we haven't gone out of our way to backport this this week, because Parsoid backports are annoying). If logspam is problematic or if it has other consequences, don't hesitate to ping our American-timezoned team members :)

The fact that it changes the behavior between Parsoid and legacy (and breaks Parsoid read views) is indeed a sign that we CTT should do something there.

Mmmmmmmmmh.
Okay, you're right. I wasn't too worried about that kind of scenario (mass reparse triggering) up until a few hours ago because up until a few hours ago those things were really independent from each other and we'd only hit the raw cache if the post-processed cache didn't have an entry.
But what I'm *currently* considering is something along the lines of "hit the postprocessing cache; if it fails, get a raw cache output, and try to see if there's another postprocessing cache entry we should hit *considering the raw cache result*". Not sure this will land yet, but this significantly increases the risk of shenanigans, and the fact that I'm at all considering this makes it a good idea to future-proof this now rather than when the cache is fuller.
Anyway. I've created T415110 to track this.

Let me document decisions a posteriori because the best time to do that was two months ago but the second best time is now.

This is the path we currently see to be able to have legacy DT in the post-processing cache, AND to be able to move away from modifying cache-varying options during the post-processing, so I'm moving this back to "current work" and doing that now.

I've looked a bit into this but didn't reach a reasonable conclusion. It might be quite specific to "ref in ref in caption"; at some point the ref is processed "normally" and at some point it's processed as a complex attribute, but I'm not sure which one should actually happen.

It looks like https://phabricator.wikimedia.org/T354009 is also suspicious on these pages: it shows "no references" in VE in the first case and it starts multiplicating references like there's no tomorrow in the second case.

This is done; post-processing cache is deployed at the same time as Parsoid Read Views for future wikis. There are still a number of follow-up tasks to be tackled, but they are filed separately.

This is not deployed to group2 yet, but my tests on hewiki and itwiki make me confident that this issue is solved. It may require purging the affected pages caches if maps are acting up.