Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow resolving issues with a release that doesn't exist yet #83696

Open
redxdev opened this issue Jan 18, 2025 · 5 comments
Open

Allow resolving issues with a release that doesn't exist yet #83696

redxdev opened this issue Jan 18, 2025 · 5 comments

Comments

@redxdev
Copy link

redxdev commented Jan 18, 2025

Problem Statement

Our team is almost entirely based around perforce, and while I understand #68525 is unlikely to be solved any time soon, one of the problems we run into with sentry being unable to see what p4 changelists exist like it can for git commits is that we can't tell sentry when specifically an issue is resolved - at best we can say "resolved in the next release" if the fix hasn't made its way into a release sentry knows about yet.

This ends up being a pretty annoying limitation, as we don't tell sentry about releases until a build is made, and the time from submitting a change to a build being created can be a day or two, with lots of other builds happening in the meantime.

This can result in the following problem:

  1. A crash is sent to sentry in release 1
  2. Someone submits a fix to the issue and marks the issue as "resolved in the next release" since they can't associate it with a perforce changelist and no release has been created yet.
  3. Release 2 is created from before the fix was submitted (maybe this was already a build in flight and so didn't have the fix)
  4. Sentry re-activates the issue because the crash happens again, despite us knowing the fix wasn't in that build

This sequence of events happens annoyingly often, and being able to specify a specific release that doesn't exist in sentry yet would be very useful for us.

Solution Brainstorm

No response

Product Area

Issues

@getsantry
Copy link
Contributor

getsantry bot commented Jan 18, 2025

Assigning to @getsentry/support for routing ⏲️

@getsantry
Copy link
Contributor

getsantry bot commented Jan 21, 2025

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

@getsantry getsantry bot moved this from Waiting for: Support to Waiting for: Product Owner in GitHub Issues with 👀 3 Jan 21, 2025
@rachrwang
Copy link

@redxdev - what would be your ideal workflow? Would it be something like "resolve in release..." and then you have an input field to type in the name of the non-existent release?

@redxdev
Copy link
Author

redxdev commented Jan 21, 2025

@rachrwang yeah, that's exactly what I think would work here. Obviously sentry can't suggest releases it doesn't know about, but if I know the exact release name/id/whatever it is I'd like to be able to enter it.

I guess there's some pitfalls with the release potentially never getting sent to sentry, but at least when sentry is operating on a release structure it can understand (like semver) it seems like it should be able to reactivate the issue if a future release has the same error again.

@getsantry getsantry bot moved this to Waiting for: Product Owner in GitHub Issues with 👀 3 Jan 21, 2025
@rachrwang
Copy link

Thanks for that context! We currently don't have bandwidth to take this on on the roadmap, though we'll file this for future efforts/ planning

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

3 participants