Improving the Resolve Feature: Seeking Community Feedback

[therealarkin]

The Resolve feature is a critical part of issue management in Sentry. It allows you to mark an issue as resolved when it's fixed or you don't expect it to happen again. You can do this manually using the button on the top left of the issue page or by including the issue ID in a commit.

However, we know that resolving issues isn't always straightforward, and we want to make sure that our Resolve feature is as helpful and intuitive as possible.

To that end, we would love to hear from you. Specifically, we're interested in hearing the following:
1/ Are you using the Resolve feature? Why or why not?
2/ If you are using:
a. What are the biggest challenges you face when using it?
b. When you fix an Issue, but someone is using an old release, do you expect Sentry to mark this as a regression or ignore old clients? Why?
c. How do you currently use the Resolve feature in your workflow? What other tools or workflows do you use alongside Sentry, and how do they interact with the Resolve feature?

Thank you in advance for sharing your thoughts with us. Please feel free to leave a comment below or reach out to our support team if you have other additional feedback or questions.

[scttcper]

Resolving via commit resolves the issue too early. Right now it resolves the issue as soon as the commit is created, this should be moved to when a release is deployed. Resolve via commit also has some issues with commits being squashed, being able to only resolve when there are commits on main/master would be preferred. For example - if a commit marks an issue as resolved, its then squashed when being landed on master with a different description (missing the "resolves SENTRY-ZZ") the issue will never unresolve since it doesn't get associated with a release.

Resolving in a commit/release isn't clear how new release versions are compared. We added support for semantic versioning - when a new event happens in a new release we compare them as either semantic versions or release dates and it isn't always clear which one is being used.

I think a feature i've always seen requested is resolved in a specific environment and ignore in lower environments. Right now, sentry has no concept of release stages (dev, stage, prod) and a release environment without the commit will unresolve the issue. We've had to tell these people to create another project for their lower environments instead.

[shaedrich]

In the GUI, Sentry already has the ability to "resolve with next release". So maybe, this is not a big deal to combine this with "resolve with commit".

[alyssaruth]

1. Yep, we use the resolve feature

a) I would echo some of the comments above about resolving via a commit - it's a nice idea but in practice we've found it doesn't work a lot of the time due to squash merging and the like. It's also easy to forget to include in the commit message - other integrations that work like this (e.g. JIRA) also work for PR titles/descriptions which gives you more flexibility / opportunity to remember. If Sentry could integrate with an organization's github and figure out which PRs landed in which release, perhaps it could do the same?

b) No - that would be very unexpected IMO. We always mark things as resolved in a particular release, and Sentry knows the order of releases - so a "regression" should only be triggered if the issue arises on that same release or later.

c) Mostly we use it manually from the Sentry UI to say that an issue is resolved when a fix has been released. We sometimes remember to try the commit thing and sometimes it works, but often it doesn't and we're back to the manual thing. In terms of tools/workflows, we're using github actions to handle our CI/CD stuff and github for our repos, PRs and so on.

[cove]

My recent issue is when there's a lot of event spam, the resolve button doesn't actually work. You have to reselect all the issues and resolve them multiple times before they're marked resolved.

[shaedrich]

It allows you to mark an issue as resolved when it's fixed or you don't expect it to happen again

So you expect different scenarios here. It might be useful to have the ability to actually denote this somehow. At least, similar to how GitHub does this with issues:

[al-the-x]

I have been using the Resolve feature with various teams for years, mostly with the Jira integration to map Active and Resolved in Sentry to corresponding statuses in Jira. Using Alerts, Sentry creates a ticket in Jira, we fix it and deploy it, and Sentry notifies us if the bug has regressed unexpectedly.

The problem arises when we want to mark an issue as Ignored in both Sentry and Jira. If I move the Jira issue to a "DONE" state, then Sentry will mark the issue as Resolved, so I need a "TODO" state in Jira to represent the "Ignored" state in Sentry. When the Sentry issue transitions to "Active" again, no corresponding state transition occurs in Jira, however. When an issue is marked as "Ignored" in Sentry, I would like to place it in a corresponding status in Jira AND have it return to a configured status in Jira when the issue recurs and becomes "Active" again.

Similarly, I would like to prevent events from a non-production environment trigging a state transition. When we have an error occur in a staging or development environment, it's usually intentional or part of a test scenario. I don't want those to trigger a regression alert. As a workaround, I have used separate projects for environments, but that's a hack and leads to configuration mistakes easily. I would really like a way to configure Alerts for regressed issues as well as new ones, so I can filter them using the same rules.

[therealarkin]

Oh wow, this is great feedback and something we haven't thought about!

[chrisvasselli]

I just migrated from Crashlytics to Sentry, and definitely used the equivalent resolve feature in Crashlytics a ton, and intend to use it in Sentry as well.

One feature I would love to see is the ability to mark something as resolved in a certain OS release. I occasionally have bugs that I cannot reasonably fix in my own app, but Apple fixes via an iOS update. I would love to have those not clutter up my issues list.

I'd also like to say that the "ignore until this affects X number of users" is a great feature that I had always wished existed in Crashlytics, and was excited to see in Sentry. 👍

[JanMikes]

Hi! We are trying to work with autoresolve via git integration, but it actually does not work well. Pretty much close as described in #47952 (comment)

There are several problems and challenges we are facing:

• We use squash for merge requests, it does not work very well - either if i mention it in squash commit message or MR description, the issue gets resolved before deployment / release (we use both sentry release and deployment tracking) happens, so sometimes we see regression, just because the commit was not deployed yet, whatover the sentry says multiple times "resolved in xxx" (MR, commit, squashed commit)

• We use multiple environments, it would be awesome to somehow be able to mark as resolved for specific environment and mark as regression only if it occurs again on the same environment - etc if we run the code for 1 day on staging for regression testing to see if it was really fixed
• With the git integration, the issue is resolved correctly but sentry unresolves it on its own for unknown reason (screen)

So by end of the day, we use the "Fixes XYZ" in commit messages/MR description only to keep reference and keep track of what fixes what, but we are forced to manually click the "Resolved in ...", as unfortunately the resolution via git is really unusable.

If it could work that the issue in Sentry would be resolved after release of the commit/MR it was tracked by, it would be awesome. And if it could understand releasing/deploying to multiple environments, it would be lovely and the best of the best!

[alyssaruth]

We use multiple environments, it would be awesome to somehow be able to mark as resolved for specific environment and mark as regression only if it occurs again on the same environment - etc if we run the code for 1 day on staging for regression testing to see if it was really fixed

+1, this has been biting us recently as well. What I really care about when I mark as resolved is that it's resolved in production, but often we'll see a "regression" because one of our CI branch environments has produced the error on a "new" version (because the branch doesn't have the fix but has newer commits).

[shaedrich]

It would also be cool if resolving an issue in staging environment it gets set to "resolved in the next release" in production environment.

[maxime1992]

Not sure of the relevance of that discussion but it's both old.. And not so old so here are my 2 cents.

Marking an issue as fixed by a commit (or from a PR mentioning the issue ID) should only close the jira ticket once that release is detected to run on prod environment. Right now as soon as we merge it's closing the associated jira ticket and that doesn't work for our current workflow as it's just in staging waiting to have some QA and then waiting to be deployed.