= Goal
We want to start getting visibility of client side errors are users are having. We'll start small to give us an insight into ways we should detect client side errors.
= Background
When the code breaks in the browser, we should notice that it is broken to fix it ASAP. Now we don't.
* [Module that captures errors in core](https://github.com/wikimedia/mediawiki/blob/master/resources/src/mediawiki/mediawiki.errorLogger.js)
* [How it is done in #uploadwizard](https://github.com/wikimedia/mediawiki-extensions-UploadWizard/blob/58a31927b0408ba6b284e433843ab15f8bf42e4a/resources/uw.EventFlowLogger.js#L188-L226)
* JS exceptions
* ResourceLoader errors
== Next steps
To start off with it may make sense to use EventLogging to detect bugs in the current code base. This would only be a short term project and would require lots of SQL queries to discover the bugs.
Longer term we'd want to use of something like Sentry and make bugs discoverable just as they are in logstash.
Subtasks have purposely not been created yet as it's not clear if we want and when we want to go down this rabbit hole :)
==AC
[] Setup [the MobileFrontendException schema](https://meta.wikimedia.org/wiki/Schema:MobileFrontendException) for capturing errors using [[ https://meta.wikimedia.org/wiki/Schema:UploadWizardExceptionFlowEvent | UploadWizardExceptionFlowEvent ]] as inspiration.
[] JS window errors are captured via `mw.trackSubscribe( 'global.error' )` and logged to the event logging schema using `mw.track( 'event.MobileFrontendExceptionEvent' )` or a `mw.eventLogging.Schema` class
[] We have informed ourselves of how we'll make use of sentry at some point when it is ready and if we can help move the project forward
[] We have a configurable sampling rate for this instrumentation, which has a sensible sampling rate so that we don't break production when there is a widespread error. Suggested initial value: 0.01 of pageviews.
[] Should be feature flagged, defaulting to false (we'll enable on one wiki)
[] This should be done in WikimediaEvents
== Open questions
Given the MinervaNeue split, we need to think about whether we want to do this in MobileFrontend or MinervaNeue. Either way result will be same but we should think about how we architect it.
== Sign off
[] Decide whether we need to update chore wheel to check Sentry errors. Is that feasible via a single SQL query?