Page MenuHomePhabricator

Spike [1hr] Investigate impact on Growth team of mobile domain removal in WikimediaEvents schemas
Closed, ResolvedPublic1 Estimated Story Points

Description

Background

The client error schema (and other schemas in WikimediaEvents) is used across teams in WMF to identify JavaScript errors in new and existing products via the associated logstash board. Currently it has a field domain which allows teams to easily determine whether a bug originates via the mobile site or desktop site (illustrated in screenshot below).

Screenshot 2025-08-25 at 6.38.29 PM.png (245×832 px, 24 KB)

With the mobile domain sunsetting this field will go away. This means teams will need to rely on the skin field instead for instrumentation and bug analysis with the caveat that some skins have different behaviours depending on whether MobileFrontend is being applied (the main impact here being on mobile). For example in the case of the client-error schema this means that in some cases the stack_trace and user agent may also need to be referenced in some analysis. In the case of ext.wikimediaEvents.createAccount you would need to distinguish accounts created on mobile or desktop via the skin field to distinguish mobile and desktop traffic.

If necessary a change could be made to add a new field to the client error schema (and other schemas) to mark whether MobileFrontend is running. The question is whether your team has sufficient need for it.

See T214998: RFC: Serve mobile and desktop variants through the same URL (unified mobile routing) (2019) for more back-story.

Suggested process

  • Talk to anyone in your team using client error dashboard and ask how they would be impacted by this change if at all (even now or in future). This should be at max a 15m conversation.
  • Review with your data analyst existing instrumentation you are relying on this quarter and check how the removal of the mobile domain would impact them
  • Report back on this ticket what you consider as blockers/risks and leave a note linking to this analysis in #we6-4_fy25-26-platform-infrastructure-risks

Event Timeline

Something that came up in backlog refinement about this task: How is all of this affecting OO.ui.isMobile()?

Something that came up in backlog refinement about this task: How is all of this affecting OO.ui.isMobile()?

OO.ui.isMobile() checks if MobileFrontend is running. It doesn't check the mobile domain. For example it is true on https://en.wikipedia.org/wiki/Mobile?useformat=mobile and https://en.wikipedia.org/wiki/Mobile?useformat=mobile&useskin=vector-2022

Something that came up in backlog refinement about this task: How is all of this affecting OO.ui.isMobile()?

OO.ui.isMobile() checks if MobileFrontend is running. It doesn't check the mobile domain. For example it is true on https://en.wikipedia.org/wiki/Mobile?useformat=mobile and https://en.wikipedia.org/wiki/Mobile?useformat=mobile&useskin=vector-2022

Ok just to make sure (also thinking of the bigger picture from T214998): In practice, the intention is to keep MobileFrontend running on mobile devices and have it not run on desktop, right? (Funny url query-parameters notwithstanding.)

If that is the case, then we will likely not be affected much. But we will do this spike nonetheless.

[…] In practice, the intention is to keep MobileFrontend running on mobile devices and have it not run on desktop, right? (Funny url query-parameters notwithstanding.)

Indeed. No funny parameters, either. The useformat parameter is offered as a developer tool to force modes (akin to uselang and useskin). In actuality, mobile pageviews will be served from the same clean canonical URL. (Varnish already varies by User-Agent today, reduced to ismobile 1/0, to decide between m-dot redirect and regular response, with the subsequent m-dot request holding the mobile response. The unified Varnish routing instead varies directly between two regular responses.)

You can test this at https://test.wikipedia.beta.wmcloud.org/ where the unified mobile routing is already live (per T401595).

KStoller-WMF set the point value for this task to 1.Sep 8 2025, 4:16 PM

We don’t seem to need extra information on the client error schema because we haven’t used the m-dot domain much to discriminate errors. In many cases GrowthExperiments has specific code paths for mobile that make it obvious from the stack trace.

I checked the “is_mobile” property on Growth custom instrumentation in https://test.wikipedia.beta.wmcloud.org and I can see it correctly set in analytic events. (We use mw.config.get( 'homepagemobile' ) which checks for Minerva in use on the server, and injects a config var)

Regarding the create account instrumentation, we are considered owners of it per https://github.com/wikimedia/mediawiki-extensions-WikimediaEvents/blob/master/OWNERS.md#specialcreateaccount-instrumentation, but T&S seem the last ones working under those folders. I haven’t seen a Growth account creation analysis. Maybe we should clarify where we stand there, but I don't think we need "is mobile" information there right now. Original task: https://phabricator.wikimedia.org/T394744 cc @KStoller-WMF

From technical pov the task is ready to sign off.

Status: ⬜ Not QA Testable
Rationale: Spike/research task only; no functional UI behavior to validate.

Agreed, I believe we can mark this as resolved.