Reducing noise by improving Issue grouping

[Dhrumil-Sentry]

Ever so often Sentry notifies you that a new Issue was detected but you’ve already seen this Issue before - you see that this latest Issue has some minor differences in the stacktraces from the original one you viewed but it’s not a new Issue

This problem can get even worse for various Javascript Issues - because there are parameterized URLs that show up in the stacktraces leading to numerous Issues getting created. We’re working on improving this experience for our users.

We are actively seeking users who’d be happy to provide feedback on Issue Grouping as a part of our Beta cohort. (Please reply below if you’re interested or drop us a note at feedback-issue-grouping@sentry.io

Here’s how we’re solving this problem in 2 phases:

Detect Similar Issues more accurately

When you view an Issue in Sentry, you can go to the new Similar Issues tab and see a list of issues that are very similar based on stacktraces and should be grouped together based according to us:

The “Would group” column represents Sentry’s opinion on whether these issue should have been grouped together instead. You can help determine the accuracy of our improvements by simply agreeing or disagreeing with these similar matchings

This process allows us to identify cases where we’d over-group otherwise causing you to miss genuinely different issues and helps us QA the improvements

Improving the grouping process itself

Once we validate that our enhancements can accurately determine issues that should be grouped together, we’ll start gradually shipping grouping improvements based on these enhancements to help reduce noise for our customers.

We need your help

We are actively seeking users who’d be happy to provide feedback on Issue Grouping as a part of our Beta cohort. (Please reply below if you’re interested or drop us a note at feedback-issue-grouping@sentry.io

We’re actively looking for feedback on grouping problems you face while using Sentry and we’d appreciate inputs on any of the following:

1. What other grouping failures do you see occurring in your Sentry? (Would appreciate any links or images!)
2. What does your workflow look like when you find duplicate issues? Do you merge them? Bulk Archive or Resolve them?

[shaedrich]

Slightly unrelated but one of the problems, I have with the "similar issues" view is that it is a little cluttered. "Issues with similar stack trace" is definitely one grouping option, but there could be more, separate sections. These sections wouldn't need all the table rows but could focus on those that are important to the grouping option to see better at the first glance if they are indeed similar (enough).

[trillville]

That's related to one idea we've been thinking about lately, currently we're referring to it as "supergroups"

Curious, do you have any examples off the top of your head for what you'd be interested in seeing in those sections?

[shaedrich]

All versions consider the fingerprint first, the stack trace next, then the exception, and then finally the message.
– from the "event/error grouping" docs/"Grouping issues" docs

• stack trace: This is a tricky one, since stack traces can have a significant depth, so this might be framework-specific or related to customized fingerprinting rules. But there are information, the stack trace has:
  • line
  • file
  • class (optional)
  • function/method (optional)
  • "block" (if condition, loop, etc.)
    
    → Furthermore, there could be some more information, also provided in the Trace navigator
  • Root: Starting transaction
  • Ancestor: Events that are descendants of the root, and are directly related to the current event
  • Parent: Event that directly started the current event
  • This Event: Node representing the current event being viewed
  • Children: Events that the current event directly started
  • Descendants: Future generations of events created by children of this event
• exception: This might have a similar problem to the stack trace in that it might depend on the parent class as well, if less
• message: I always felt like exception and message are so tied together, they might be the same grouping option and message just being one level deeper within exception (essentially exception.class and exception.message). So the question here is more like whether exception.class AND exception.message have to be the same to be seen as similar or if one of them is enough
• fingerprint: Well, technically, this would need all the options below
  • error.type
  • error.value
  • message
  • logger
  • level
  • tags.tag_name
  • stack.abs_path
  • stack.module
  • stack.function
  • stack.package
  • family
  • app

Hope, that helps

[deoomen]

Maybe an option to also manually merge issues will be good? For now we can merge issues only when Sentry mark them as similar. But sometimes Sentry does not see similarity but in out opinion there are the same issue.

For example:

<?php

$array = null;

echo $array['b];
echo $array['c'];

Above example will produce two separate issues (Warning: Trying to access array offset on null) in Sentry but "Similar issues" tab is empty.

[Dhrumil-Sentry]

@deoomen Thanks for this feedback! Users can merge issues from the issue stream too- Does this not work?

Would you consider the errors in your example to be the same issue even if they were occurring in slightly different stacktraces?

[deoomen]

Exactly. Stacktrace is slightly different but in this example it's only line number. And whole context is the same. So it'll be useful that we can merge those issues. Or maybe link somehow issues as related?

[spaceemotion]

I am indeed very much interested in better issue grouping. In my current project most of the errors are getting picked up incorrectly and thus make it very hard to filter out each error type on its own.

They all share the same stack trace, but the messages are different since they come from a 3rd party API.

[Dhrumil-Sentry]

@spaceemotion Thanks a lot for this feedback!

They all share the same stack trace, but the messages are different since they come from a 3rd party API.

Are these issues getting grouped into a single issue? Do you prefer them to be grouped as different issues?.

If you have any specific examples of such poorly grouped issues- please feel free to share the URLs to feedback-issue-grouping@sentry.io

[spaceemotion]

@Dhrumil-Sentry hey there, i wanted to send a mail, but i'm getting a Delivery Status Notification (Failure) from your mail service:

We're writing to let you know that the group you tried to contact (feedback-issue-grouping) may not exist, or you may not have permission to post messages to the group. A few more details on why you weren't able to post:

 * You might have spelled or formatted the group name incorrectly.
 * The owner of the group may have removed this group.
 * You may need to join the group before receiving permission to post.
 * This group may not be open to posting.

If you have questions related to this or any other Google Group, visit the Help Center at https://support.google.com/a/sentry.io/bin/topic.py?topic=25838.

Thanks,

sentry.io admins

[Dhrumil-Sentry]

@spaceemotion Sorry for the trouble ! I had to update a setting on the google group 🤦. Can you please resend 🙏