Only one error is sent to Bugsnag per page load

[JacobEvelyn]

I've got a throw "TEST"; line in my Angular code in a controller and it successfully notifies Bugsnag the first time that page is seen, but not after that. I wasn't sure if Angular was doing any tricky caching so I did this and still see the same behavior:

$scope.test = function () { throw "TEST" }();

Any thoughts on what's causing this behavior? And whether this is in this code or Bugsnag's?

[wmluke]

Hi @JacobEvelyn,

What version of angular-bugsnag are you using? Versions 0.1.3 and above refresh the bugsnag client rate limit after each $locationChangeSuccess event.

Additionally, in Chrome Developer Tools, do you see an image request for https://notify.bugsnag.com/js?notifierVersion=2.4.7&apiKey=XXXX.... after each exception?

[JacobEvelyn]

I bumped up to 0.1.4, but in testing before the change I was seeing this behavior there as well. Only one image request is made per page load.

[wmluke]

Interesting. I don't see this behavior in the Test App.

Perhaps, there's a browser issue. Would you mind laughing the test app in your local env and testing?

$ git clone [email protected]:wmluke/angular-bugsnag.git
$ cd angular-bugsnag
$ gulp serve

Additionally, you'll need to punch in a Bugsnag API Key here.

[JacobEvelyn]

Interesting. It looks like the behavior is a bit more subtle than I realized. It seems Bugsnag doesn't send the same request twice in a row (you can test this by running the test app and clicking the same link multiple times in a row). Can you reproduce this in the test app on your machine?

[foxyblocks]

Hello,

Bugsnag team member here.

Interesting. It looks like the behavior is a bit more subtle than I realized. It seems Bugsnag doesn't send the same request twice in a row (you can test this by running the test app and clicking the same link multiple times in a row). Can you reproduce this in the test app on your machine?

This is correct. We check to see if an error is identical to the previous one before sending it. We found that a client would often get caught in an infinite loop and send a wad of duplicate errors. Usually in these cases it was only the first error event that was useful, since they all stem from the same cause.

Perhaps you can help me understand the use case for when you would want it to behave differently and we can incorporate that into the library.