# Background
The client error schema (and other schemas in [[ https://github.com/wikimedia/mediawiki-extensions-WikimediaEvents/tree/master/modules | WikimediaEvents ]]) is used across teams in WMF to identify JavaScript errors in new and existing products [[ https://logstash.wikimedia.org/app/dashboards#/view/AXDBY8Qhh3Uj6x1zCF56?_g=h@218e8f9&_a=h@65ec81f | 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).
{F65912887}
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 [[ https://github.com/wikimedia/mediawiki-extensions-WikimediaEvents/blob/master/modules/ext.wikimediaEvents.createAccount/useInstrument.js | 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.
# 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