.NET grouping

Hi Alex,

The way the grouping works is somewhat complex and takes into account several aspects of an exception (inner exception, line in the stack trace, method names).

You're running our latest grouping algorithm but have clearly stumbled on a shortcoming. I'll get one of our engineers who's worked on the grouping to take a look at improving this scenario. I suspect we need to take into account more lines in the stack trace for some exception types (we'll start by taking a look at a SQLException).

Hopefully we'll have something sorted for you soon - thank you for drawing our attention to it!

John-Daniel Trask
Co-founder
Mindscape

Hi Alex,

Just updating this - Callum on our team has revised the grouping code in our test environment. He's now feverishly adding more unit tests and functional tests to ensure it's doing the right thing. I hope we'll have something released later this week and we can then upgrade your grouping to this model going forward. Effectively it takes into account all lines in the stack trace, and the stack trace lines for any inner exceptions if they exist also.

Being able to do custom grouping via how you send data is an interesting idea. You could add this to our feature request section of the forum if you're keen on it. My thinking would be that you could perhaps just set a "grouping key" property when it was sent up and, if set, the code could just use that. Might be the best way. I'm not 100% sold it's the right thing to have this feature at all, but just thinking out loud about it :-)

I'll update the thread once Callum's code has jumped the hurdles needed to make it into production.

Kind regards,

John-Daniel Trask
Co-founder
Mindscape

Hi Alex,

I can announce that Raygun now has updated grouping logic for .NET exceptions. This solves several cases that you may have noticed, including the SQLExceptions being grouped together. All new applications created from now will use the new logic.

The effect of this is that errors are now assigned new groups as they are hashed based on their contents using different logic. The implication being that as errors flow in, they will no longer be assigned to their old groups - some of which may have been set to ignore, or renamed. These will reappear and have their new groups set to ignore again.

On the plus side, errors that would have previously been grouped erroneously will be split out and named correctly based on their actual message. As this solves the issue you noticed we believe this is a necessary step to take.

To avoid all old applications having their ignored/renamed issues disrupted we have a versioning mechanism. Currently your existing applications are set to use the previous grouping logic so they will remain undisrupted. We can set it to use the updated logic at your request. As stated previously, new .NET applications created from now will use the updated algorithm, however.

If this is acceptable and you'd like us to switch one or all of your applications over, let us know here or via email or Feedback (within the app) and we'll action the request.

Regards,

Callum Gavin
Software Developer
Mindscape