The issue is that all NullReferenceException have got the same messages so they are added to the same group when I look at them on the App Center website. Would it be possible to take into account the stacktrace to group them instead of the message? In my opinion that would make more sense as different crashes happening at different locations ends up in the same group because of that. My workaround was to generate a hash code based on the stacktrace and to prepend it to the message to separate them into different groups.
Hi @supersolid-corentin,
Thanks for reporting this! I've relayed this message to our crashes engineering team and they would like some more information to troubleshoot if what you're experiencing is currently an expected behavior or a bug on our end. Would you mind starting a conversation in the blue chat bubble located at the bottom right corner of your screen? You can mention this Github thread and our support team will route the conversation to our engineering team.
Thanks so much!
Thank you for the answer, I just started a conversation using that feature.
Is there any news or ETA on this? I also noticed the crashes or exceptions being grouped by the message instead of the stack trace which does not make much sense to me.
It was confirmed as a bug but I didn't receive any ETA so I would be happy to know more as well.
Our engineering team will have the bandwidth to further investigate this bug next week. I'll post an update then. Thanks for the patience!
Update: our team hasn't had a chance to investigate this yet. This is prioritized and we will look at it as soon as we have the bandwidth. Thanks for everyone's patience.
Hi all! So our engineering team spent a few days looking at this. For context, our grouping logic takes into account many different factors including the stack trace, line numbers, exception message, method and class name.
It looks like some crashes are being grouped by the exception message because our backend is not correctly parsing the class and method names. At this time we are unsure what the underlying root cause is, and due to other priorities, we won't have time to further investigate at the moment. I will monitor this thread and see if this is affecting more users as this might help us spot trends and troubleshoot the problem.
In the meantime, you can search by method and class names so hopefully, that helps you filter your relevant crash groups. I understand this is a less than ideal experience and I will update this thread if we have any other findings. Thanks!
@winnieli1 is it possible to document current grouping logic in the help section on the website? thanks
Hmm... Are you still haven't time to investigate that annoying feature/bug?
Any news?
This still seems to be an issue. The following 2 exceptions are grouped for me, which does not make sense in my opinion:
"type": "RestEase.ApiException",
"message": "GET \"https://example.com/api/v1/do/something/1\" failed because response status code does not indicate success: 400 (Bad Request).",
"type": "RestEase.ApiException",
"message": "GET \"https://example.com/api/v1/do/someotherthing/456\" failed because response status code does not indicate success: 400 (Bad Request).",
I obfuscated the URLs. Also the Stacktraces are different.
We also have occurrences of exceptions that have both different stack traces (same exception type) and different messages, yet they are grouped together.
I'd say that the exceptions should be grouped only if they have the same stack trace and exception type - in the example above it's fine to have under the same group multiple RestEase.ApiException reports if they have the same stack trace (even if they report different http status codes via their message property).
Also, in the example above, having the same stack trace and exception type should mean most of the time the same URL.
@winnie Any progress on this, please?
We're facing similar issues with iOS / Objective-C crash reports. There are many different crash reports that end up grouped together and the only thing they have in common is the top line of the stack trace: objc_msgSend
Any news on this?
Most helpful comment
Our engineering team will have the bandwidth to further investigate this bug next week. I'll post an update then. Thanks for the patience!