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