The only correct way to send purges to the edge caches is doing that after the last layer of inner cache has been regenerated, or, if it's not regenerated, when it's invalidated. This means that if we generate parsoid cached output via a job on every edit/transclude, we should have that job spawn a ParsoidCdnPurgeJob (or maybe parametrize the current CdnPurge job, given the only thing changing would be the URLs?). That's a mechanism that is proven and would take a short implementation time too.

PCS is a different problem - mostly it depends on how we'll manage the internal caching for it.

After some discussion, we collectively realized that WikiPage::doPurge will invalidate all relevant parser cache entries, and any resource-change event emitted by it applies to output of parsoid and the old parser alike. This makes it a lot easier to reason about things, we don't have to worry about when things actually get written to the parser cache.

Is this still a valid concern/ticket? I think that at this point if we:

• Disable storage for parsoid incoming requests (in progress)
• Disable pregeneration for parsoid

all the requests are going to hit MW and eventually parser cache that has an existing mechanism for purges.

Overall in terms of purging needs after disabling storage:

• ParserCache is handled internally in MW
• We still have rules for /page/html to be purged on resource change events. That should be good enough in order to remove the stored parsoid dependency from RESTBase.
  • We have rules on changeprop to emit purge via /sys/queue/events to purge edge /page/html

In T344946#9541833, @Jgiannelos wrote:

• We still have rules for /page/html to be purged on resource change events. That should be good enough in order to remove the stored parsoid dependency from RESTBase.

Right now, we still do pre-generation in restbase. We should stop doing that ASAP. Then we will also no longer hit core after template changes.

• Have have rules on changeprop to emit purge via /sys/queue/events to purge edge /page/html

We do need purge events to be sent to the edge caches for /w/rest.php/v1/(page|revision)/.*/(with_)?html. Currently, responses from these endpoints have a very short TTL. Once we have pirge events in palce, we can fix that.

I seem to recall that @Joe said there was a new system for this in place, instead of (or on top of?) changeprop. I don't recall the details. It would be good to know if we can up the TTL on these responses.