> 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@...> 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 [email protected] https://lists.wikimedia.org/mailman/listinfo/qa
