[QA] Investigate logging common JavaScript exceptions

[Gergo Tisza]

> 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