<no message value> entries in Sentry from raven.js

[momoadeli]

Versions:
raven.js 3.5.0
Sentry: 8.3.3
Exception Handler: AngularJS 1.5.8

Hi,
I have one of the following in my AJS exception handler. This generates 'no message value' entries but more detailed content.

Raven.captureException(exception);

This, however, has a proper message header but much less detail in the content:

Raven.captureException(exception.stack);

For visual reference, I have the following generated in Sentry depending on when I pass 'exception.stack' vs 'exception' to Raven.captureException: Thoughts greatly appreciated.

[genintho]

I "fixed" this issue by editing https://github.com/getsentry/raven-js/blob/master/dist/raven.js#L1237 and always passing a message

var data = objectMerge({
 message: message,
 // sentry.interfaces.Exception
 exception: {
 values: [{
 type: type,
 value: message,
 stacktrace: stacktrace
 }]
 },
 culprit: fileurl
 }, options);

[momoadeli]

@genintho, thanks! However, we're feeding off the CDN and not forking the source. That said, point taken, you seem to be indicating this is a bug.

[momoadeli]

Has anyone had a chance to review this? Many thanks!

[benvinegar]

Which version of Angular? And if it's 1.x, are you using the Angular plugin (plugins/angular.js)?

However, we're feeding off the CDN and not forking the source. That said, point taken, you seem to be indicating this is a bug.

You can use the example above via setDataCallback (lets you mutate the outbound data object).

[biggestT]

@benvinegar I also encountered this issue with Sentry 8.2.3, Angular 1.4.11, Raven.js 3.4.1 and using the Angular plugin.

Since this commit: fbf1d1b Raven doesn't set data.message and the angular plugin: https://github.com/getsentry/raven-js/blob/master/plugins/angular.js#L55-L63 never sets data.message either if it doesn't match the pattern (which none of the exceptions I tried to throw within my angular components did). From my understanding this is the cause of all the <no message value> entries.

Not sure if the best fix is to just keep setting it as in the fix mentioned above or if the angular.js plugin should be changed.

[benvinegar]

There should still be an exception type/value. For example, I'm seeing the following:

{
 "type":"Error",
 "value":"[$compile:tpload] Failed to load template: partials/phone-list-derp.html (HTTP status: 404 Not Found)\nhttp://errors.angularjs.org/1.4.7/$compile/tpload?p0=partials%2Fphone-list-derp.html&p1=404&p2=Not%20Found"
}

Unless the regex is matching, but returning empty strings for those values (match[0] and match[1]), in which case the original type/values are overwritten with nothing.

I'm experimenting with this locally, and I'm having difficulty triggering the types of errors where the regex matches this way. @biggestT, @megabyzus – do you have example exceptions that trigger this scenario?

[benvinegar]

To clarify: Sentry doesn't need a message attribute. It will use the exception type/value to assemble the message. If all three of those values are blank, however, you would see <no message value>.

[momoadeli]

@benvinegar Apologies, just saw your comments and questions. I have my setup in the OP, however, here it is again (I believe the CDN below includes the AJS plugin/intergation per documents):

raven.js 3.5.0 <script src="https://cdn.ravenjs.com/3.5.0/angular/raven.min.js"></script>
Sentry: 8.3.3
Exception Handler: AngularJS 1.5.8

I can easily reproduce the problem. Merely initialize a variable to an undeclared one somewhere and run the app:

var testVar = notDeclared

The sentry results are:

I get the same results with our without my own exception handler (note if I pass 'exception.stack' to captureException instead of 'exception' only, I get a better Sentry title but the guts are culled.--see image below):

 var globalExceptionHandlerModule = angular.module('globalexceptionhandlermodule',[]);

 globalExceptionHandlerModule.factory('$exceptionHandler', ['$log', function($log) {

 return function myExceptionHandler(exception, cause) {
 // logErrorsToBackend(exception, cause);
 $log.error(exception, cause);
 Raven.captureException(exception);
 // Raven.captureException(exception.stack);
 };

 }]);

[biggestT]

@benvinegar I haven't been able to throw any exceptions that matches the pattern but what I see is that if they don't match no message key is in the payload. In the payload there is an exception key that looks like this:

"exception":{"values":[{"type":"Error","value":"test","stacktrace":{"frames":[{ ... [long stacktrace omitted] ..

So the type and value is there but it seems like my self hosted Sentry (v8.2.3) needs an explicit message key in order to display a title in the GUI. We "solved" this by downgrading to raven-js 3.1.1 (version without the commit that removed the explicit setting of message was introduced). With that we get both the above exception key in the payload as well as a
message key which makes the GUI present a title for all Exceptions we have encountered so far.

[benvinegar]

Sentry: 8.3.3

@megabyzus @biggestT – okay, I totally missed this piece of information. You're using older on-premise versions.

And yeah, this is the cause. In Sentry 8.6 we made some changes so that the message interface is no longer necessary. I should have noted this in my release notes for raven-js. An oversight on my part; I am developing against getsentry/sentry master almost 100% of the time.

So, a couple ideas here:

1. revert back to raven-js 3.4.x ... OR
2. upgrade your Sentry to 8.6 (tougher)

I also recommend, if you are using on-premise Sentry, you should be pinning you raven-js versions explicitly.

[momoadeli]

@benvinegar Yes, this issue has been resolved. Thanks!

[vladgurovich]

We "solved" this by downgrading to raven-js 3.1.1 (version without the commit that removed the explicit setting of message was introduced).

....

And yeah, this is the cause. In Sentry 8.6 we made some changes so that the message interface is no longer necessary.

@benvinegar these seem like breaking changes that shouldve had more signal than a minor version bump IMHO

[benvinegar]

@vladgurovich – totally fair; we'll try to better assess behavior changes as they correspond with Sentry server versions going forward.