Skip to content
This repository has been archived by the owner on Jan 25, 2018. It is now read-only.

Integrate Raven-JS for error logging to sentry #387

Merged
merged 1 commit into from
Feb 7, 2014

Conversation

jaredlockhart
Copy link
Contributor

  • Depends on ravenjs
  • Sends a msg to Zamboni to proxy error messages to sentry through the VPN
  • Binds to window.onerror but allows for custom logging using Raven.captureMessage(msg)

Refs #942912

@jaredlockhart
Copy link
Contributor Author

Also I want to mention that this does two things:

  • Sets up Raven to talk to a Zamboni server
  • Binds an event handler to window.onerror so that some level of errors (JS engine level errors) are captured and sent.

It's left up to the developer to provide a richer set of logging to their code when they want messages sent to Sentry through Zamboni. We provide a wrapper called raven_proxy.

For instance if you want to log a failed ajax transaction you might do something like:

require(['raven-proxy'], function (raven_proxy) {
$.ajax(url, {
...
error: function (xhr, status) {
raven_proxy('failed transaction');
}
});
});

require(['settings'], function (settings) {
Raven.config(settings.zamboni_raven_url, {}).install();

window.onerror = function(errorMsg, url, lineNumber) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably a good idea to explicitly return false to ensure the default handling happens.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@muffinresearch
Copy link
Contributor

Might be nice to make the inclusion of this based on config too, just so it's easy to turn on or off for each env.

# Please note that the leading 'none@' is required
# The trailing integer '12345' is the sentry account id which is found in a sentry DSN
# ex: https://<user>:<pass>@app.getsentry.com/<sentry_account_id>
'zamboni_raven_url': 'TODO',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This means that by default raven will be enabled, but fail?

Would prefer an empty string and if there is an empty string, skip sending to raven.

We'll need to change this on a per server basis so add it to https://github.com/mozilla/webpay/tree/master/webpay/settings/sites

@jaredlockhart
Copy link
Contributor Author

I've modified our proxy to check whether it's been initialized and provided a wrapper.

@andymckay
Copy link
Contributor

Could you put the bug number in the commit messages first line please, usually (bug xxxxxx) on the end.

@jaredlockhart
Copy link
Contributor Author

Done.

}
}

// Define an includable reference to the proxy
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could wrap this file in the define rather than having the require and then an inner define.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I tried that but it seems that the inner body of a define is only evaluated when it's included in another file that requires it, so Raven will not be initialized and bound to window.onerror at page load by default (say if it's not specifically required by another module).

It's handling two cases, one is to automatically initialize and bind to the global window handler, and the other is to provide a manually invokable proxy. Is there some better way to organize it that satisfies both of those cases?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could require it here: js/pay/pay.js that's sort of like the main file. This will be a lot cleaner/clearer in spartacus.

@jaredlockhart
Copy link
Contributor Author

camelCased!


Raven.captureMessage(message, options);
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing semicolon

@muffinresearch
Copy link
Contributor

As mentioned at the work week after thinking on it and looking at the Raven source code I'm not sure we should use our own client instead of Raven.js because it has a bunch of potentially useful features see http://raven-js.readthedocs.org/en/latest/config/index.html#optional-settings

The Raven client uses a GET because it's using image beacons (via Image objects) to poke stacktraces into sentry (albeit in our case we're using a mirror) so we're not needing to workaround the same origin policy that most people would if they're sending errors to sentry directly.

When this lands we'll want to get QA eyes on the webpay flow just look out for any problems with the implementation. (Add qa+ to the whiteboard in bugzilla)

@andymckay
Copy link
Contributor

Would upstreaming a patch to raven-js that allows us to do GET or POSTs be an option?

@muffinresearch
Copy link
Contributor

Would upstreaming a patch to raven-js that allows us to do GET or POSTs be an option?

Could try that - though my feeling is they might see adding support for POST as a bit of an edge-case, but I could be wrong.

@muffinresearch
Copy link
Contributor

Looks like there's an existing patch started for this: getsentry/sentry-javascript#89

@andymckay
Copy link
Contributor

And it says he'd consider it if someone made it configurable. So we've just go to do that... :)

- Depends on ravenjs
- Sends a msg to Zamboni to proxy error messages to sentry through the VPN
- Binds to window.onerror but allows for custom logging using Raven.captureMessage(msg)
@andymckay
Copy link
Contributor

r+ from me

@muffinresearch
Copy link
Contributor

r+ lgtm

andymckay pushed a commit that referenced this pull request Feb 7, 2014
Integrate Raven-JS for error logging to sentry
@andymckay andymckay merged commit 7893b75 into mozilla:master Feb 7, 2014
@mattrobenolt
Copy link

Let me know if there's anything I can do to help!

With regard to POSTs, my hunch is that this is the direction we're going to go: getsentry/sentry-javascript#183

These pluggable transports will work similar to the way they work in raven-python, for example, that way it can be treated as a plugin and not included in core. This way you could register a DSN like: https+post://... and control how that's sent for your environment.

Either way, I'd gladly accept upstream patches!

@muffinresearch
Copy link
Contributor

@mattrobenolt that sounds great!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants