Allow "Resolve in next release" to use those only in the same environment as the issue

[henrahmagix]

Problem Statement

I work with a Staging and a Production environment on the same codebase: Staging releases are made automatically for every git commit, so we name them by the git commit hash, whilst Production releases are made manually so we name them by the datetime e.g. 2024-12-03-1038.

As far as I'm aware, Sentry uses chronological ordering when Semantic Versioning is not detected. This part works great for us because we create releases sequentially and never make backport releases.

However, using "Resolve in the next release" on an issue in the Production environment ends up marking it as resolved when the next Staging release is created. This is incorrect for us: the issue occurred in Production, so we only want it to be resolved by a Production release.

Can it be possible please to ensure issues marked as resolved in an upcoming release, are only resolved by those appearing in the same environment as the issue?

Thanks in advance, Henry ☺

P.S. Semantic Versioning doesn't work for us unfortunately

Solution Brainstorm

• add a project configuration option to separate releases by their environment
• use that option when "Resolve in the next release" option is chosen on an issue

Product Area

Issues

[getsantry]

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

[scttcper]

@henrahmagix thanks for writing in that makes sense, I've added this to our backlog

[edgariscoding]

I recently created a similar ticket for this same issue/feature. You worded it much better than I did

My issue: #83480

This would be an amazing feature, we also only care if the feature was resolved in the prod environment.

If I mark a Sentry issue in Prod as resolved in the next release, what happens is that the next release for Dev or Sandbox will likely not include the fix yet and i'll get a regression alert. We have a new dev/sandbox release for each merged PR so the fix will not always be merged right after setting the resolution status to "resolved in next release".

I'd love to have an option to set issue to "Resolved in next {ENVIRONMENT} Release" where we could set the environment ourselves or have it automatically populate based on the environment for the current issue.

[gurutechstu]

I need this too. It's very annoying to mark a prod issue as resolved in next release, push a fixed version to staging, and then have prod say it regressed before the fix is posted. I just barely realized this has been the behavior the whole time and have wondered why so many things are regressing

[leeandher]

This feature request and this one are quite similar and something we as a team should look to get built out together. I'll resurface this with the team, and see if we can appropriately prioritize this, though historically I believe the way we've structured environments makes this a bit challenging. The comments in both threads speak to the problems developers are encountering though so I will be sure to make that known.

Thank you for voicing your feedback! The larger variety of use-cases we understand, the more useful this feature can become.