Help us improve the Suspect Commit feature

[therealarkin]

Suspect Commit has been a game-changer for many of you, we are seeing a significant increase in Error Resolution Rate & reduced resolution time for orgs that enabled Suspect Commit.
[If you haven’t used suspect commit, please enable it, instructions here]

From our own experience, we know that it's not perfect every single time, and we're looking to make improvements to make it even better. That's why we're reaching out to our community of users to get your feedback.

If you've used Suspect Commit, we're curious to know the following:

1. In what cases has Suspect Commit been helpful to you?
2. In what cases hasn't Suspect Commit been useful? And why?
3. Are there any other things that we should consider to make Suspect Commit even more effective?

As a reminder here is what Suspect Commit Looks like for those who enabled it. (Read more here)

Thank you for being a part of the Sentry community, and looking forward to your feedback

[Komal1223]

@therealarkin I have tried earlier suspect commit with my development environment but I am unable to see it for the production environment. What could be the reason?

[brianthi]

Hi @Komal1223! We have documented how to get Suspect Commits working here. If you're still not able to get it working, please file a support ticket (https://support.sentry.io/) and our team will do their best to help you out.

[therealarkin]

Thanks @brianthi & @Komal1223! @Komal1223, please let us know how it goes; I'll also respond by email.

[irvansemestanya]

1. It is helpful if latest blamed commit line is the root cause.
2. It is not helpful if it is red-herring, because previous commits are actually one to blame. So any way to quickly swipe to previous commits similar to looking at previous commits git blame at Github will be helpful, especially if we recently reformat/refactor code, so unrelated commits suspected

3. Please consider for us to tell you exactly which commit are the one making issue in case the issue happens again (regression) or even while the issue is ongoing so multiple people looking at same Sentry issue page won't be misled with wrong suspect commit.

[therealarkin]

Thanks @irvansemestanya!

All points are great. Super grateful for the engagement here!
Good news: We had an internal discussion, and we are seriously considering 1+2 as part of our roadmap!

We'll need to think more about #3. We have an "Assignee," but we totally understand that the person who is assigned to fix might not be the person who touched the code last, and it is useful for the assigned to talk with that person. A workaround, for now, could be to add a comment in the activity tab but understood it's not optimal

[shaedrich]

Maybe, below the assigne, you could list other people like

• Code owner
• Committer
• Commit author (if different from committer)

Optionally, next to the names, you could offer shortcuts to

• re-assign
• at-mention in comments

[irvansemestanya]

I just realized that Sentry has commenting system, hahaha. Thanks, that's great!

[shaedrich]

As far as I can see, there's currently no way to tell sentry whether the suspect commit is the actual commit that causes the issue. Maybe two buttons ("Yes, this is the right commit" and "No, please try again") might be helpful. This way, sentry would get helpful insight and people looking at the issue could actually assign a commit that can be shown as such and not just as a suspect.
Maybe additionally, if connected to GitHub or GitLab, one could even add a comment or note to the commit to have the information also in version control.
It would be even more interesting if one could use that commits SHA (or file + line(s)) as a search filter to see if that very change caused more than this one issue.

[doc-sheet]

Hi!
Is it ok to use string formatting for sql queries like this?

pd_id expected to be integer but just to be consistent isn't it better to use sql parameters or orm?

/cc @cathteng