[QA] Investigate logging common JavaScript exceptions

[Chris McMahon]

FWIW, you might want to read Jim Evans on the subject:
http://jimevansmusic.blogspot.com/2013/09/capturing-javascript-errors-in.html

On Wed, Feb 25, 2015 at 3:39 PM, Gergo Tisza <gtisza at wikimedia.org> wrote:

> > On Tue, Feb 24, 2015 at 2:53 AM, Sam Smith <samsmith <at> wikimedia.org>
>
>
> I'm working on adding generic Javascript error logging to the Wikimedia
> cluster. I hope to make it work reliably on the beta cluster within a week
> or two, and deploy it to production some time next quarter, so this might
> or might not be useful to you depending on where and how urgently you need
> error logging.
>
> There is an RfC [1] which is somewhat outdated but gives a good overview of
> what are the moving parts of an error logging system. Since then we have
> decided to use Sentry [2] as the error aggregator/user interface. That's
> not well documented yet, but there is an infrastructure plan at [3] and a
> demo page at [4]. You can follow current work in [5].
>
>
> > >> 2. Is it possible?
> > > Sure. See GlobalEventHandlers.onerror [1].
>
> The short answer is that it's possible but not necessarily easy. The long
> answer is outlined in the RfC.
>
> > >> 3. How would we do it?
>
> The big problem with global error logging is how to differentiate between
> your errors and errors caused by other components/site
> customizations/browser extensions/etc. If you want to log browser tests
> errors in a controlled environment, this is less of a problem; if you want
> to log live errors, the records that are interesting to you will be a
> fraction of the total logs.
>
> At the moment, I don't have a good solution for this; identifying where an
> error originates from is going to be hard until ResourceLoader gets source
> map support, which is several quarters away.
>
> If you can live with this limitation, error reporting should Just Work
> (once Sentry has been deployed). Otherwise, you can add try-catch blocks
> manually and then tag the errors with the module name or other identifying
> information - there will be helper functions to do that and to report the
> errors which are caught.
>
>
> Jon Robson <jrobson at ...> writes:
> > I wonder is if the browser tests can log any JavaScript console errors
> > it encounters during test runs somewhere. This would be added
> > protection for us to prevent errors leaking into production. I've
> > cc'ed QA in case they have any ideas about that.
>
> This should be pretty simple to set up once the core patches for JS error
> logging [6] are merged. If you want the errors in Sentry just make sure
> Jenkins enables the Sentry extension and sets a few site config vars. If
> you want them in the test artifacts, I'm not sure a clean solution exists
> for that, but since the exceptions will be published in the
> errorLogging.exception mw.track event stream, one could write a small
> MediaWiki extension which stores that in a cookie / localstorage from where
> they can be retrieved at the end of the test.
>
>
> [1] https://www.mediawiki.org/wiki/Requests_for_comment/Server-
> side_Javascript_error_logging
> [2] https://getsentry.com/welcome/
> [3]
> https://docs.google.com/a/wikimedia.org/presentation/d/1kdSdtLFev6r9rirI35n
> 9QUrU9-3J5XgYk00vDJrqISI/edit
> [4] http://sentry-beta.wmflabs.org/jserrors/jserrors/group/15/
> [5] https://phabricator.wikimedia.org/T1345
> [6]
> https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/core+branc
> h:master+topic:js-errorlogging,n,z
>
>
>
> _______________________________________________
> QA mailing list
> QA at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/qa
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/qa/attachments/20150225/cfb6e5b9/attachment.html>