Given issues like T145569, I suggest this audit be a high priority issue rather than normal technical debt.

If I'm not mistaken the source of {T145569} is enqueuement in the service layer, not in the origin. I believe @GWicke et al are looking into options. Agreed, though, this is important stuff as a general matter.

@bmansurov is Reading Web tech lead this Q2 (and probably Q3, it's typically a six month rotation) and will be working with the team on its prioritization of tech debt.

In T121466#2688928, @dr0ptp4kt wrote:

If I'm not mistaken the source of {T145569} is enqueuement in the service layer, not in the origin. I believe @GWicke et al are looking into options. Agreed, though, this is important stuff as a general matter.

Yeah sorry, I meant it in a general manner that "caching issues are causing UBNs" so I think it's more cause to be proactive so we don't need to be rushed and reactive later.

In T121466#2688928, @dr0ptp4kt wrote:

If I'm not mistaken the source of {T145569} is enqueuement in the service layer, not in the origin.

I don't have access to that task, so can't comment. Could anybody give me the needed access bits, or summarize here?

Audit the usage of cache in the following extensions to make sure any cache that stores expanded or rendered wikitext is using page_touched and not page_latest for caching:

I just spent 30 minutes looking through our extensions and the only place I can see which operates directly with wikitext is MobileFrontend and TextExtracts (both use getTouched). QuickSurveys operates with config and mediawiki messages; Popups and RelatedArticles just hit APIs.

I'm pretty confident reading web's extensions don't make use of getLatest / getTouched or directly page_touched or page_latest outside MobileFrontend but I'm not sure how to clearly convince you @Legoktm ... is there anything tangible you would like from us?