Add ability to ignore specific issues in a particular (app) version

[ediazest]

Problem Statement

This is a problem mostly relevant to mobile clients, where old versions of our app might remain in use longer than we'd prefer.

We send logs from our apps to monitor and detect issues as they occur. Sometimes, an issue spikes in a certain version and starts flooding Sentry. After fixing the issue, due to the nature of mobile apps and our user base, it may take quite some time to update most users to the newest version.

What this means for us is that the buggy version not only floods Sentry but also continues to contribute even after the issue is fixed, until the version is fully dropped by users. We could filter out the release altogether, but we don't consider this a valid option as we still want to be alerted if further issues arise in this version.

This is particularly important in events generated by Sentry, like the 'App Hanging' event on iOS, because we can't easily switch off the event for a particularly buggy version, and we also don't want to filter out the entire issue. Another example would be an event that we use to track if something should not happen and build alerts based on that specific event.

It would be great if we could ignore specific issues for a specific version X or between versions X and X+1, so they remain visible in version X+2.

Solution Brainstorm

When something like this happens, our current approach has been renaming logs so we can completely filter out the previous issue, which sort of works but also requires reactive effort and requires updating monitoring tools/links. Additionally, this isn't straightforward when events are generated by Sentry, such as the 'App Hanging' event on iOS.

Perhaps these 'automatic' events could include an extra identifier in the title to allow for filtering, but I'm not sure if it's always clear what additional information to add in the title, nor if it's easy to anticipate this problem in future events.

Ultimately, to address both use cases, I believe that improving the 'inbound filtering' option to allow for more advanced filtering, which might include release version, name, issue ID, OS, and not just 'error message', would be a significant enhancement

Product Area

Issues

[getsantry]

Assigning to @getsentry/support for routing ⏲️

[souredoutlook]

I am going to pass this on to our issues team as I do believe what you're asking for is a feature request that would be an enhancement to our current Delete and Discard workflow -> "Delete and Discard for x.y.z release"

I did want to chime in and say it is currently possible to filter by Release: https://docs.sentry.io/product/data-management-settings/filtering/#releases

If you aren't self-hosting or don't have a Business tier plan you can also consider creating a new client key per production release which can successfully mock this inbound filter but obviously requires some extra steps. This can be done programmatically with the API at build time: https://docs.sentry.io/api/projects/create-a-new-client-key/

I personally think creating a client key per production release is better than inbound filtering on release because if you have a Business tier plan you can rate limit issues and errors but retain other data that would otherwise be filtered by the releases inbound filter.

Even if you have a team plan when you ship a unique client key with each production release you can easily turn off those client keys on the Sentry server and all traffic will be blocked at the click of a button.

[getsantry]

Routing to @getsentry/product-owners-issues for triage ⏲️

[roggenkemper]

Thanks for the suggestion! I agree that the workflow you described does sound useful and as you and Nick mentioned, there are a few ways this would be achieved. There is work ongoing at Sentry about improving inbound filters which might help solve the problem or this could be solved from the Issues side. I've added it to our backlog but Im unsure of when exactly we'll be able to add this feature. Thanks again for your thoughts!