Change Details

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 ==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 == Sign off [] Decide whether we need to update chore wheel to check Sentry errors. Is that feasible via a single SQL query?

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 ==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?

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 ==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?