In T400855#11079175, @BBlack wrote:

@Krinkle - Diving into the specifics a bit (I think all of this will be clearer if you make a prototype VCL patch for phase 1 maybe), and re-stating/asking things for clarity:

• The VCL plan is more or less this?
  • The current mobile_redirect VCL code should, instead of actually redirecting to m-dot, just set the X-Subdomain header and carry on with the direct request.
  • Edge caches should vary on the X-Subdomain set above
  • Edge caches should still rewrite the m-dot domain to the desktop domain before talking to MediaWiki
  • When the host header of the incoming domain was already m-dot, should the VCL run the mobile_redirect code anyways and dynamically set X-Subdomain, or should it just force X-Subdomain: m because the request was for m-dot? (I suspect the former)
  • Inside the mobile redirect conditional logic, what do we do with the special conditions like:
    • && req.http.Cookie !~ "(stopMobileRedirect=true|mf_useformat=desktop)"
    • && req.url !~ "[?&]mobileaction=toggle_view_desktop(&|$)"
  • ^ It seems like maybe we need to add an inverse condition for at least ?mf_useformat=mobile, maybe something eles with toggle_view, etc?

In T400855#11080062, @Krinkle wrote:

For this task, I mainly want to review the purge strategy. Today, the MobileFrontend extension uses a single mechanism to decide whether a wiki uses an m-dot domain or the same-domain. This controls output (where the "Mobile view" link points, and where the <link rel=alternate> tag points) and controls whether MediaWiki emit purges for m-dot URLs.

@BBlack That sounds correct, yes.

Today: Canonical requests sometimes redirect to m-dot, and m-dot requests always render a mobile version.

Future: Canonical requests sometimes redirect to m-dot, canonical requests sometimes render a mobile version, and m-dot requests always render a mobile version.

I believe the following is how this works today:

• In vcl_recv > cluster_fe_recv_pre_purge, we rewrite m-dot requests to add http.X-Subdomain = "M"; and turn m-dot domains back into canonical domains.
• In vcl_recv > cluster_fe_recv > mobile_redirect, we return a synthetic redirect to an m-dot domain if
  • 1) request method is GET/HEAD,
  • 2) and, request has a mobile user agent,
  • 3) and, the request does not opt-out (e.g. opt-out cookies, or mobile-ish UA that prefers desktop, or a Googlebot-for-Commons request as of T397267).
  • 4) and, the request is not a toggle request (mobileaction) which are POST-like in that MobileFrontend will respond to such request by saving an opt-out cookie on the current domain, and then redirecting to the "other" domain (mobile to desktop, or desktop to mobile).
  • 5) is a mobile-enabled domain (i.e. the canonical domain of a MW-powered site with MobileFrontend enabled and an m-dot DNS entry)

The first change is effectively:

• change the m-dot clause that sets X-Subdomain = "M" to do so for these pilot domains as well.
• change the opt-out condition to include a sub clause with a list of pilot domains that we won't redirect. (This may be redundant in implementation, since we already exclude X-Subdomain from redirects. While that should be an impossible condition today, it's a safe guard we could start relying on explicitly to avoid needing to duplicate or store the list.)

A later second change will be to redirect m-dot to canonical, but that is several months out and not in play right now.

This is why the purge strategy is important, because it means during the transition period we want MobileFrontend to primarily act as if there is no m-dot domain, but still support m-dot traffic. For pageviews that's fine because we'll use the same X-header to enable it. It won't know the difference. But... purges. Unless we do develop something new, we'd serve stale content on m-dot URLs, right?

In reviewing the cluster_fe_recv_pre_purge code today, I was surprised to see the m-dot translation is "pre purge" without any (obvious) guard from happening on purge requests. This suggests a PURGE for https://en.m.wikipedia.org/wiki/Main_Page is translated into a purge for https://en.wikipedia.org/wiki/Main_Page (with an X-header that Varnish presumably ignores), which in turn suggests that we don't really need to be emitting these duplicate purges in the first place. Is that so?

In T400855#11083499, @ssingh wrote:

[Just as an FYI, @BCornwall will be working from Traffic on this.]

Status quo analysis

vcl_recv@wikimedia-frontend
* call cluster_fe_recv_pre_purge@text-frontend
  * always unset req.http.X-Subdomain and req.http.x-dt-host
  * if req.http.host has m-dot,
    set req.http.X-Subdomain
  * if req.http.X-Subdomain,
    set req.http.x-dt-host to req.http.host with m-dot changed to canonical
* if PURGE { … }
* call cluster_fe_recv@text-frontend
  * call mobile_redirect@text-frontend
    * if req.http.X-Subdomain, then no redirect (sanity guard)
  * if req.http.X-Subdomain and beta cookie, return pass

vcl_backend_response@wikimedia-frontend
* call cluster_fe_backend_response@text-frontend
  * if bereq.http.X-Subdomain and url has (mobileaction|useformat), shorten ttl to 60s

rb-mw-mangling.lua@trafficserver::backend::mapping_rules
* on TS_LUA_HOOK_CACHE_LOOKUP_COMPLETE (after cache lookup, before origin fetch)
  * if req.http.X-Subdomain, set Host = x-dt-host.

vcl_deliver@wikimedia-frontend
* call deliver_synth_
  * call analytics_deliver_post
    * if req.http.X-Subdomain, add x_analytics[ismobile]=1

For an en.m.wikipedia.org request:

• varnish:
  • cluster_fe_recv_pre_purge: add req.http.X-Subdomain=M
  • cluster_fe_recv_pre_purge: add req.http.x-dt-host=(canonical host)
  • (handle purge, separate for m-dot and canonical)
  • (cache lookup, separate for m-dot and canonical)
  • (fetch from ATS backend)
• ATS:
  • (cache lookup, separate for m-dot and canonical)
  • rb-mw-mangling.lua: change Host to x-dt-host
  • (fetch from MediaWiki, varies by X-Subdomain)
  • (store in cache, separate for m-dot and canonical)
• varnish:
  • vcl_backend_response: shorten ttl for m-dot responses for (mobileaction|useformat) URLs
  • (store in cache, separate for m-dot and canonical)
  • analytics_deliver_post: add x_analytics[ismobile]=1

For an en.wikipedia.org request with mobile user agent:

• varnish:
  • (handle purge, separate for m-dot and canonical)
  • mobile_redirect: do a redirect to the m-dot equivalent, ... unless there is an opt-out cookie, url not pageview-like (/wiki or title=), or otherwise excluded for somem reason.

Open questions

The most minimal change that might work is to edit mobile_redirect and when the domain name is in a given list (e.g. regex (foo.example|bar.example)), set X-Subdomain = M instead of a redirect.

I considered moving the mobile-related steps from cluster_fe_recv_pre_purge to mobile_redirect. At glance that seems safe because nothing else uses these fields before that point. Unlike what I wrote at the end of T401595#11090457, these do not affect purging because we merely add x-dt-host, we don't change host itself until we make the MW request at the ATS backend. But..., there is one exception: RESTBase URLs under /api/rest_v1. For those, we do change the host header in Varnish pre-cache and pre-purge. This is presumably because 1) we support use of RESTBase endpoints on m-dot URLs, and 2) we do not allow RESTBase to vary its responses, and 3) we do not have ChangeProp configured to purge both URLs (it'd be inefficient to do so, anyway). As such, we can't easily move this. So.. back to the minimal change.

If we do the minimal change, then there's a few side effects to consider:

• varnish: there will be two places that set X-Subdomain instead of just one.
  • @BCornwall Is that fine?
• varnish: mobile_redirect will no longer always redirect.
  • @BCornwall Shall I just rename this?
• varnish: cache lookup for canonical URLs must deal with the fact that responses may now vary by X-Subdomain (by proxy of user agent). This should be fine given we implemented T390929: MobileFrontend should declare "X-Subdomain" variance via "Vary" response header.
• ATS: cache lookup for canonical URLs must deal with responses varying by X-Subdomain. Should be fine.
• ATS: As-is, rb-mw-mangling.lua would start to act on both m-dot requests and mobile canonical requests. It currently reads x-dt-host unconditionally which is wrong.
  • @BCornwall Shall I fix this by checking x-dt-host?
  • Long-term we can rename X-Subdomain:M to X-Mobile:1 to make it less confusing that ATS sees a "X-Subdomain" request that in fact has no m-dot subdomain. It just means "Enable MobileFrontend", and from the MediaWiki perspective it already means just that (the header name is configurable).
• varnish: As-is, vcl_backend_response would effectively no longer shorten the TTL for mobile responses to (mobileaction|useformat) URLs. It is unclear to me why this logic exists or why it is specific to m-dot URLs today. The same parameters have been in use on desktop URLs for a decade and seemingly fine without it, so I suggest we leave it as-is, we once 100% of m-dot traffic is redirecting, we can remove this as unused logic.

In T401595#11090484, @Krinkle wrote:

1. Status quo analysis

Wonderfully reviewed and detailed. I came to the same conclusions as well during a review.

• 1. Open questions
• varnish: there will be two places that set X-Subdomain instead of just one.
  • @BCornwall Is that fine?

I think that's fine with appropriate commenting

• varnish: mobile_redirect will no longer always redirect.
  • @BCornwall Shall I just rename this?

I don't think the name is a big deal. Particularly since there's a lot of reworking going on (See T370200) I wouldn't fuss too much about it.

Change #1180166 had a related patch set uploaded (by Krinkle; author: Krinkle):

[operations/puppet@production] varnish: Merge m-dot and X-Subdomain block in cluster_fe_recv_pre_purge

https://gerrit.wikimedia.org/r/1180166

Change #1180220 had a related patch set uploaded (by Krinkle; author: Krinkle):

[operations/puppet@production] varnish: Write docs for some mobile user agent regexen

https://gerrit.wikimedia.org/r/1180220

Change #1180228 had a related patch set uploaded (by Krinkle; author: Krinkle):

[operations/puppet@production] varnish: Remove legacy `^(lge?|sie|nec|sgh|pg)` mobile regex

https://gerrit.wikimedia.org/r/1180228

Change #1180577 had a related patch set uploaded (by Krinkle; author: Krinkle):

[operations/puppet@production] varnish: Implement new direct routing for mobile views

https://gerrit.wikimedia.org/r/1180577

Change #1180166 merged by BCornwall:

[operations/puppet@production] varnish: Merge m-dot and X-Subdomain block in cluster_fe_recv_pre_purge

https://gerrit.wikimedia.org/r/1180166

Change #1180220 merged by BCornwall:

[operations/puppet@production] varnish: Document mobile user agent regexen and mobile_redirect logic

https://gerrit.wikimedia.org/r/1180220

Change #1180919 had a related patch set uploaded (by Krinkle; author: Krinkle):

[operations/puppet@production] trafficserver: Check x-dt-host in rb-mw-mangling.lua before using

https://gerrit.wikimedia.org/r/1180919

Change #1180919 merged by BCornwall:

[operations/puppet@production] trafficserver: Check x-dt-host in rb-mw-mangling.lua before using

https://gerrit.wikimedia.org/r/1180919

Change #1180957 had a related patch set uploaded (by Krinkle; author: Krinkle):

[operations/puppet@production] trafficserver: Fix confusion in rb-mw-mangling_test.lua cases

https://gerrit.wikimedia.org/r/1180957

Change #1180957 merged by BCornwall:

[operations/puppet@production] trafficserver: Fix confusion in rb-mw-mangling_test.lua cases

https://gerrit.wikimedia.org/r/1180957

Change #1181310 had a related patch set uploaded (by Krinkle; author: Krinkle):

[operations/mediawiki-config@master] Enable wmgUseMdotRouting in Beta Cluster for testwiki only

https://gerrit.wikimedia.org/r/1181310

In T401595#11113593, @gerritbot wrote:

Change #1181310 had a related patch set uploaded (by Krinkle; author: Krinkle):

[operations/mediawiki-config@master] Enable wmgUseMdotRouting in Beta Cluster for testwiki only

https://gerrit.wikimedia.org/r/1181310

The Varnish logic is staged on the Beta Cluster and active on https://test.wikipedia.beta.wmcloud.org/ only.

When hit with a mobile user agent, it correctly renders the mobile view instead of the desktop view, without a redirect.

We MW config patch to go along with it, is not yet live. This means "Mobile view" on desktop still points to m-dot (and works fine).

In testing this, I noticed that the opt-in/opt-out logic works somewhat counter to my previous mental model.

The opt-in "Mobile view" link uses mobileaction=toggle_view_desktop and routes to the mobile domain, but this query parameter doesn't do anything. The MobileFrontend extension 1) doesn't set a cookie on the canonical domain on departure and so subsequent hits on the desktop domain don't go the mobile view, and 2) doesn't set a cookie on the receiving domain either because the m-dot domain is persistent enough by itself that no cookie is needed. Subsequent navigations within the same short-lived sessions naturally stay within the same experience.

The opt-out "Desktop view" link on the other hand (mobileaction=toggle_view_mobile) sets a stopMobileRedirect cookie. This is needed as otherwise it would redirect right back.

Without an m-dot domain, the MobileFrontend extension uses mf_useformat='' and mf_useformat='true' cookies on the same domain instead. However:

• Varnish looks for mf_useformat=desktop which does not exist anywhere in the MobileFrontend codebase today it seems. I'm guessing this was either an unused draft, typo, or something that changed over ten years ago (the mismatch in both Varnish and MF trace back to 2014, I gave up after that).
• The MobileFrontend logic will not consider this cookie anyway, because the header takes precedence in MobileContext::shouldDisplayMobileViewInternal.

In T401595#11102625, @gerritbot wrote:

Change #1180577 had a related patch set uploaded (by Krinkle; author: Krinkle):

[operations/puppet@production] varnish: Implement new direct routing for mobile views

https://gerrit.wikimedia.org/r/1180577

• When a mobile clients opt-out and prefer desktop, they will set a stopMobileRedirect cookie. This already works as expected and is handled correctly in the new router as well.
• When a desktop clients opt-in to mobile, they will set a mf_useformat=true cookie. This is not yet handled correctly in my new router. We need to treat this cookie the same as we do mobile user-agents, like the inverse of "stopMobileRedirect". Today, the opt-in link simply navigates the user to the m-dot domain and that functions as a cookie without needing a cookie (naturally sticky for the same browsing session, since links are relative and stay within that domain). If we don't handle this new inverse cookie, the opt-out link won't work at all.

I've also figured out how to handle the paradox between the Varnish and MW wmf-config change. Previously it seems there was no good way to do it.

• A: Varnish-first. This is mostly fine, but means mobile clients temporarily can't reliably opt-out via the "Desktop view" button.
• B: MediaWiki-first. This means toggling isn't aware of the domain requirement and thus doens't work at all.

When we include the handling of the mf_useformat cookie globally (not limited to pilot wikis), then it all works out. The old logic doesn't set this cookie so existing traffic is unaffected.

Rollout procedure:

1. Setting MW first is fine because the majority of traffic is handled by the edge redirect still and unchanged. Those using the toggle links will leverage the new logic naturally.
2. Setting Varnish second then takes care of the incoming traffic to use the new logic as well.

The reverse can work as well. For example:

1. Set Varnish first to stop redirecting and respond in-place. "Mobile view" and "Desktop view" continue with their old logic. The Desktop toggle would set stopMobileRedirect cookie, which the new router understands as well. The mobile toggle would still point to the m-dot URL and works fine, and we'd still advertise <link rel=alternate>
2. Set MW second to stop advertising and switch mobile toggle to set a same-domain cookie via the unified router.

Change #1180969 had a related patch set uploaded (by Krinkle; author: Krinkle):

[operations/puppet@production] [WIP] varnish: Improve 08-mobile-hostnames-rewrite.vtc

https://gerrit.wikimedia.org/r/1180969

Change #1180228 merged by BCornwall:

[operations/puppet@production] varnish: Remove legacy `^(lge?|sie|nec|sgh|pg)` mobile regex

https://gerrit.wikimedia.org/r/1180228

Change #1181310 merged by jenkins-bot:

[operations/mediawiki-config@master] Enable wmgUseMdotRouting in Beta Cluster for testwiki only

https://gerrit.wikimedia.org/r/1181310

Mentioned in SAL (#wikimedia-operations) [2025-08-28T23:11:06Z] <krinkle@deploy1003> Started scap sync-world: Backport for [[gerrit:1181310|Enable wmgUseMdotRouting in Beta Cluster for testwiki only (T401595)]]

Mentioned in SAL (#wikimedia-operations) [2025-08-28T23:13:07Z] <krinkle@deploy1003> krinkle: Backport for [[gerrit:1181310|Enable wmgUseMdotRouting in Beta Cluster for testwiki only (T401595)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2025-08-28T23:22:00Z] <krinkle@deploy1003> Finished scap sync-world: Backport for [[gerrit:1181310|Enable wmgUseMdotRouting in Beta Cluster for testwiki only (T401595)]] (duration: 10m 54s)

Change #1182963 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/extensions/MobileFrontend@master] docs: Clarify code comments around doToggling

https://gerrit.wikimedia.org/r/1182963

@Jdlrobson-WMF Do we want mobileaction params to remain in the address bar after toggling?

In a simple setup (as you might have locally, and third parties, without mobile domain), MobileFrontend points to mobileaction foter links with a normal pageview in the desired mode, and a cookie to preserve the choice. This is easy to reason about and is similar to useformat. It does, however, mean these URLs are not great for sharing or caching:

1. a recipient of a shared article has their mode preference changed and saved. This is surprising.
2. the URL is incompatible with CDN caching, because it is non-canonical and with cookie-setting side-effects.

In production, MobileFrontend has historically behaved differently. We do an ad-hoc redirect during the toggle. If I understand the code comments in MobileContext->doToggling, these redirects are to "bring" you to the correct domain. In practice, at least in recent years, the "Desktop view" and "Mobile view" links already point to the destination domain. On the receiving end, doToggling effectively performs a same-domain redirect (canonical-to-canonical, or mobile-to-mobile). While this seems a no-op at first, it's actually good because it strips the mobileaction parameter while at it, thus bringing the user to a URL suitable for sharing, and CDN caching.

You can test this locally in the default setup, and (as of today) on the Beta Cluster testwiki:
https://test.wikipedia.beta.wmcloud.org/wiki/Main_Page

I propose we change this to redirect always, thus avoiding the above two issues, by behaving the same as we do today.

Change #1182967 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/extensions/MobileFrontend@master] MobileContext: Do post-toggle redirect also without mobile domain

https://gerrit.wikimedia.org/r/1182967

Change #1180969 had a related patch set uploaded (by Krinkle; author: Krinkle):

[operations/puppet@production] varnish: Improve 08-mobile-hostnames-rewrite.vtc

https://gerrit.wikimedia.org/r/1180969

I need a bit more time to read through what your proposing (and reminding myself of how this all works) but some early thoughts

@Jdlrobson-WMF Do we want mobileaction params to remain in the address bar after toggling?

I don't think so. When sharing it's best those don't show up in the URL, especially if they have side effects such as setting a cookie. This could either be done using history.replaceState or on the server (if not used). I think the reason they are there is because we didn't have history API back in 2012 when we wrote this code to normalize the URL after the link was followed.

a recipient of a shared article has their mode preference changed and saved. This is surprising.

Yeh that's not good. That seems like a bug. We don't want people sharing URLs that force people into the desktop or mobile experience.

Feel free to review if you have the time, though note that Tim is my main collab on this for code review, so don't feeel you have to. My patch implements/preserves current prod behavior, as that seemed most likely to me. I wanted to confirm this before asking for review (because if it wasn't, I'd update the patch to do the opposite instead). Thanks!

Change #1183212 had a related patch set uploaded (by Krinkle; author: Krinkle):

[operations/puppet@production] varnish: Remove 60s cap for mobileaction/useformat on m-dot

https://gerrit.wikimedia.org/r/1183212

Change #1180969 had a related patch set uploaded (by Krinkle; author: Krinkle):

[operations/puppet@production] varnish: Improve 08-mobile-hostnames-rewrite.vtc

https://gerrit.wikimedia.org/r/1180969

Change #1182963 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] docs: Clarify code comments around doToggling

https://gerrit.wikimedia.org/r/1182963

Change #1182967 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] MobileContext: Do post-toggle redirect also without mobile domain

https://gerrit.wikimedia.org/r/1182967

Change #1183281 had a related patch set uploaded (by Krinkle; author: Krinkle):

[operations/mediawiki-config@master] Enable wmgUseMdotRouting in Beta Cluster for remaining wikis

https://gerrit.wikimedia.org/r/1183281

Change #1183281 merged by jenkins-bot:

[operations/mediawiki-config@master] Enable wmgUseMdotRouting in Beta Cluster for remaining wikis

https://gerrit.wikimedia.org/r/1183281

Change #1183700 had a related patch set uploaded (by Krinkle; author: Krinkle):

[operations/mediawiki-config@master] Disable wmgUseMdotRouting on testwiki in prod

https://gerrit.wikimedia.org/r/1183700

Change #1184117 had a related patch set uploaded (by Krinkle; author: Krinkle):

[operations/mediawiki-config@master] Disable wmgUseMdotRouting on Test Wikidata, Wikitech, and Office Wiki

https://gerrit.wikimedia.org/r/1184117

In T401595#11130418, @gerritbot wrote:

Change #1181310 merged by jenkins-bot:

[operations/mediawiki-config@master] Enable wmgUseMdotRouting in Beta Cluster for testwiki only

https://gerrit.wikimedia.org/r/1181310

In T401595#11134787, @gerritbot wrote:

Change #1183281 merged by jenkins-bot:

[operations/mediawiki-config@master] Enable wmgUseMdotRouting in Beta Cluster for remaining wikis

https://gerrit.wikimedia.org/r/1183281

This is how I've tested that the purges are still sent correctly by the hook in wmf-config.

https://gerrit.wikimedia.org/g/operations/mediawiki-config/+/11097cf91e5437b5ff0036a3da84123e80bde21d/wmf-config/LabsServices.php#51

krinkle@deployment-mediawiki13:~$ sudo curl -d 'POST' 'https://nl.wikipedia.beta.wmcloud.org/w/index.php?title=Reclame2&action=purge' --connect-to ::deployment-mediawiki13 -vi

krinkle@deployment-mediawiki13:~$ sudo tcpdump -t -v -X -K -i any dst host deployment-eventgate-4.deployment-prep.eqiad1.wikimedia.cloud | grep -i -C10 Reclame

on/json..user-agent:.MediaWiki/1.45.0-alphaContent-Length:.1221....
[
{"$schema":"/resource_change/1.0.0","meta":{"uri":"https://nl.wikipedia.beta.wmcloud.org/wiki/Reclame2","request_id":"76f204b3-e97c-46e4-b1e8-e64f71bc78af","id":"458923aa-ea21-4b4c-a5fe-c59ea07c8a7f","domain":"nl.wikipedia.beta.wmcloud.org","stream":"resource-purge"},"tags":["mediawiki"]},
{"$schema":"/resource_change/1.0.0","meta":{"uri":"https://nl.wikipedia.beta.wmcloud.org/w/index.php?title=Reclame2&action=history","request_id":"76f204b3-e97c-46e4-b1e8-e64f71bc78af","id":"3b5250a1-4d07-4299-a18a-0b3d12937850","domain":"nl.wikipedia.beta.wmcloud.org","stream":"resource-purge"},"tags":["mediawiki"]},
{"$schema":"/resource_change/1.0.0","meta":{"uri":"https://nl.m.wikipedia.beta.wmcloud.org/wiki/Reclame2","request_id":"76f204b3-e97c-46e4-b1e8-e64f71bc78af","id":"f82b00ce-f8bc-40a5-8573-db8b595afb7d","domain":"nl.wikipedia.beta.wmcloud.org","stream":"resource-purge"},"tags":["mediawiki"]},
{"$schema":"/resource_change/1.0.0","meta":{"uri":"https://nl.m.wikipedia.beta.wmcloud.org/w/index.php?title=Reclame2&action=history","request_id":"76f204b3-e97c-46e4-b1e8-e64f71bc78af","id":"c08aaa3c-efa1-4ea9-989
5-65212aad7866","domain":"nl.wikipedia.beta.wmcloud.org","stream-

-on/json..user-agent:.MediaWiki/1.45.0-alpha..Content-Length:.288....
[{"$schema":"/resource_change/1.0.0","meta":{"uri":"https://nl.wikipedia.beta.wmcloud.org/wiki/Reclame2","request_id":"76f204b3-e97c-46e4-b1e8-e64f71bc78af","id":"b444a708-6099-442e-8480-96a964caee97","domain":"nl.wikipedia.beta.wmcloud.org","stream":"resource_change"

Change #1184126 had a related patch set uploaded (by Krinkle; author: Krinkle):

[operations/puppet@production] varnish: Enable unified routing on test.wikidata, wikitech, officewiki

https://gerrit.wikimedia.org/r/1184126

Mentioned in SAL (#wikimedia-operations) [2025-09-03T16:35:46Z] <sukhe> sudo cumin "A:cp" "disable-puppet 'merging CR 1180969'": T401595

Change #1180969 merged by Ssingh:

[operations/puppet@production] varnish: Improve 08-mobile-hostnames-rewrite.vtc

https://gerrit.wikimedia.org/r/1180969

Mentioned in SAL (#wikimedia-operations) [2025-09-03T16:43:41Z] <sukhe> merging CR 1183212: T401595

Change #1183212 merged by Ssingh:

[operations/puppet@production] varnish: Remove 60s cap for mobileaction/useformat on m-dot

https://gerrit.wikimedia.org/r/1183212

Change #1180577 merged by Ssingh:

[operations/puppet@production] varnish: Implement new direct routing for mobile views

https://gerrit.wikimedia.org/r/1180577

Mentioned in SAL (#wikimedia-operations) [2025-09-03T17:01:42Z] <sukhe> rolling out CRs 1180969, 1183212, 1180577, -b31 A:cp: T401595

Change #1183700 merged by jenkins-bot:

[operations/mediawiki-config@master] Disable wmgUseMdotRouting on testwiki in prod

https://gerrit.wikimedia.org/r/1183700

Mentioned in SAL (#wikimedia-operations) [2025-09-03T23:57:28Z] <krinkle@deploy1003> Started scap sync-world: Backport for [[gerrit:1183700|Disable wmgUseMdotRouting on testwiki in prod (T401595)]]

Mentioned in SAL (#wikimedia-operations) [2025-09-04T00:00:48Z] <krinkle@deploy1003> krinkle: Backport for [[gerrit:1183700|Disable wmgUseMdotRouting on testwiki in prod (T401595)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2025-09-04T00:06:59Z] <krinkle@deploy1003> Finished scap sync-world: Backport for [[gerrit:1183700|Disable wmgUseMdotRouting on testwiki in prod (T401595)]] (duration: 09m 30s)

Change #1184886 had a related patch set uploaded (by Krinkle; author: Krinkle):

[operations/puppet@production] varnish: factor out unified_mobile_domain_regex

https://gerrit.wikimedia.org/r/1184886

Change #1184886 merged by Ssingh:

[operations/puppet@production] varnish: factor out unified_mobile_domain_regex

https://gerrit.wikimedia.org/r/1184886

Mentioned in SAL (#wikimedia-operations) [2025-09-05T14:08:37Z] <sukhe> enabling puppet on cp3068: testing CR 1184886 T401595

Change #1184126 merged by Ssingh:

[operations/puppet@production] varnish: Enable unified routing on test.wikidata, wikitech, officewiki

https://gerrit.wikimedia.org/r/1184126

Change #1184117 merged by jenkins-bot:

[operations/mediawiki-config@master] Disable wmgUseMdotRouting on Test Wikidata, Wikitech, and Office Wiki

https://gerrit.wikimedia.org/r/1184117

Mentioned in SAL (#wikimedia-operations) [2025-09-05T14:30:53Z] <krinkle@deploy1003> Started scap sync-world: Backport for [[gerrit:1184117|Disable wmgUseMdotRouting on Test Wikidata, Wikitech, and Office Wiki (T401595)]], [[gerrit:rMW1184131a8dc2|Disable wmgUseMdotRouting on mediawiki.org (T403510)]]

Mentioned in SAL (#wikimedia-operations) [2025-09-05T14:36:12Z] <krinkle@deploy1003> krinkle: Backport for [[gerrit:1184117|Disable wmgUseMdotRouting on Test Wikidata, Wikitech, and Office Wiki (T401595)]], [[gerrit:rMW1184131a8dc2|Disable wmgUseMdotRouting on mediawiki.org (T403510)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2025-09-05T14:44:33Z] <krinkle@deploy1003> Finished scap sync-world: Backport for [[gerrit:1184117|Disable wmgUseMdotRouting on Test Wikidata, Wikitech, and Office Wiki (T401595)]], [[gerrit:rMW1184131a8dc2|Disable wmgUseMdotRouting on mediawiki.org (T403510)]] (duration: 13m 40s)

Congrats on the milestone!

I'd like to review how this impacted traffic to the mobile site (and review the user agents getting the mobile site) - presumably we should be be getting more mobile (Minerva) traffic now because wikitech and office wiki previously didn't redirect to mobile. Is that a fair assumption?

In T401595#11153001, @Jdlrobson-WMF wrote:

[…] presumably we should be be getting more mobile (Minerva) traffic now because wikitech and office wiki previously didn't redirect to mobile.

Office Wiki was configured correctly like any other prod wiki, no change there.

Wikitech indeed was broken (T190384#11153446), and as following the 5 Sep rollout, it now has mobile pageviews: https://w.wiki/FH7E