Every report goes into "NotProvided"
akos
Posted on
May 29 2014
Hey,
We've just started using Raygun and so far it seems great and works fine with our Android client. However, every report that our iOS client sends has no message and class name, so they go into a single category called "NotProvided".
Am I doing something wrong? Can you help me out here?
Thanks
paulb00th
Posted on
Oct 14 2014
Hi,
We're also getting many (but not all) of our exceptions grouped under "NotProvided". Would be helpful to get a response from Raygun devs about this.
Thanks,
Paul.
Jason Fauchelle
Raygun
Posted on
Oct 14 2014
Hi Paul,
We have a solution to this which I am hoping to release within the next 2 weeks. Apologies for the inconvenience here, I'll update this thread when the solution is available.
-Jason Fauchelle
Punters
Posted on
Oct 31 2014
Also getting the same issue with all iOS reports being thrown into NotProvided.
EDIT: New ones that are coming through now, seem to be splitting out correctly.
Jason Fauchelle
Raygun
Posted on
Nov 10 2014
Hi everyone,
The latest version of the Raygun4iOS provider (v1.4.2) will include the iOS error signal information in each error report. We then use this information to help the grouping logic in the case where the message is "NotProvided". This is not a perfect solution, as errors with the same signal codes will be grouped together, but this will be far better than throwing every error into the "NotProvided" group. We'll continue working on the iOS error grouping in this case to improve it further.
The latest version of the provider can be obtained through CocoaPods, or from the download link here: https://raygun.io/raygun-providers/ios
Let us know if you have further questions.
-Jason Fauchelle
John Davalos
Posted on
Mar 27 2015
Hi Jason,
We're seeing this same issue with our Rails application. All of the Request details say "Not Provided". Are we doing something wrong on our end? We just started using Raygun, and it's been a breeze to setup.
Thanks, John
John Davalos
Posted on
Mar 27 2015
I think we managed to figure it out. we're passing the request into the env, and that's getting most of what we want.