The root cause is that PCS doesn't ensure that the URL is valid, just sends a purge event for the incoming URL. This should be fixed here:

Yeah a fix was deployed yesterday.

The same applies for bnwikisource. See diff:
https://prv-tests.wmcloud.org/diff/bnwikisource/%E0%A6%85%E0%A6%B6%E0%A7%8B%E0%A6%95_%28%E0%A6%B8%E0%A7%81%E0%A6%B0%E0%A7%87%E0%A6%A8%E0%A7%8D%E0%A6%A6%E0%A7%8D%E0%A6%B0%E0%A6%A8%E0%A6%BE%E0%A6%A5_%E0%A6%B8%E0%A7%87%E0%A6%A8%29%2F%E0%A6%AD%E0%A7%82%E0%A6%AE%E0%A6%BF%E0%A6%95%E0%A6%BE

I updated the SLO page to refer to the existing prometheus buckets and not use p75 and p95 cause the might be ambiguous

I started with the desktop definitions with an MR here (because they match the buckets better): https://gitlab.wikimedia.org/repos/sre/slothslos/-/merge_requests/53

I only added it just to be on the safe side that we only refer to traffic that hits mw-web. From what I've seen so far the metric is very specific to page views so I think we can remove the filter.

@JMeybohm 👋 I updated the draft after your feedback.

I am very not familiar with FlaggedRevs but it looks like this might be problematic:

• https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlaggedRevs/+/1330099/14/includes/frontend/FlaggablePageView.php
• This returns a status object and not the parser output which eventually is used as an argument for addPostProcessedParserOutput

Duplicate of T434524

I am not sure what ideal means. Is it the current state? Is it where we want to go for increase in logged in read views? If the latter, will the SLO fail? I think it would be good to work together with someone more familiar with SLOs to move forward.
Other than the reconciliation part, its also not clear to me how we move forward after we fill all the template sections.

Hey @JMeybohm! Its not very clear how we can move forward on the "Reconciliation" part of the SLO template. Will you be able to help us with that?

I think the problem is a combination of:

• Old vandalized version of a page
• Url requested not encoding the article part
  • This means that for the page with: https://de.wikipedia.org/api/rest_v1/page/summary/<title>/<id>
    • This will always render the page with id=<id>
    • This should have been: https://de.wikipedia.org/api/rest_v1/page/summary/<title>%2F<id>
• Cache pregeneration request not escaping the /<id> part

This fixes things locally:

Draft published here: Wikitech/SLO/Mediawiki page view

After this ^ patch locally, i am getting the same titles:

I think this is a side effect of how prop=parseroutput gets populated not a real parseroutput metadata issue.

I don't think fonts should affect mathjax. My understanding is that mathjax implements the compatibility layer (including fonts).

From staging:

We have been using rt-testing on mw-parsoid for quite some time. Closing this one.

I don't think its parsoid related. I've tried this with useparsoid=0 and its reproducible with legacy as well.