Configure ignore button for slack integration

[lukio3]

Problem Statement

On the slack integration as above, I want to be able to press ignore and know what version of 'ignoring' I am doing, is it:

• ignore forever?
• ignore until next occurance?

I have this granularity in the sentry web app, I would like the same in the slack integration

Solution Brainstorm

Add dropdown to ignore button on slack with some options (at least "ignore until next time")

[getsentry-release]

Routing to @getsentry/ecosystem for triage. ⏲️

[jonesphillip]

@lukio3 appreciate the feedback! Going to add this to the backlog, although we likely won't have the bandwidth to address this in the near term. Will keep this thread updated.

For anyone else looking at this, please 👍 this if interested and we will prioritize it higher.

[meysam81]

@BYK
Where should I look to change to fix this?

[JohnDuncanScott]

This is a super important feature even if it seems simple. For new users to the tool, the default Ignore functionality of "ignore forever" is, in my opinion, not something most teams would want and it's really easy to press and forget this. The Slack integration compounds this by not giving the other options. I've already had to undo permanent ignores multiple times and it's easy to forget. A step towards fixing this would be to change the label in Slack and the UI to "Ignore forever" / "Ignore permanently", as that makes it clearer and reduces human error. Many users seem to assume that the default Ignore just ignores it once. Adding the other options in Slack is then a bonus :). This current rough edge is also exacerbated by this bug: #24497 - so essentially the default Ignore functionality seems to break the state for an undetermined period of time.

[BYK]

@meysam81 that's a @manuzope question and I just pinged him now 😁

[manuzope]

Hi @meysam81, here's the line for the Ignore:

sentry/src/sentry/integrations/slack/message_builder/issues.py

Line 216 in dff2eb1

ignore_button = {"name": "status", "value": "ignored", "type": "button", "text": "Ignore"}

However, before you begin coding it up, it's worth discussing what you see as the solution so that we're not iterating at the time of the PR.

[meysam81]

@manuzope Thanks for your reply. Sure, I'll take a look and get back to you with how I plan to solve this in a day or two (a full-time job and a passion to contribute to open source has to be coordinated 😁 ).

[meysam81]

@manuzope
You mentioned that I should discuss how I would approach this; so, from my understanding, I have a rough idea that this is where needs to change:

https://github.com/getsentry/sentry/blob/master/src/sentry/integrations/slack/endpoints/action.py#L287

The action variable can be updated like this:

action.update(ignoreDuration=60, snoozeDuration=60)

The arguments to update comes from here:

https://github.com/getsentry/sentry/blob/master/src/sentry/api/helpers/group_index/validators/group.py#L26:L30

Let me know if I'm on the right path.

P.S. We are reaching the end of Hacktoberfest, so although I have a passion for contribution, would you please speed this up a little so that I can complete my challenge? 🙏

Another P.S. How did you insert the code block? I pasted the link but it didn't format the UI. Is it a special markdown that Github supports?

[scari]

The same question the OP had got me here. If this feature request is still valid and you'd want to have it on the future release of Slack integration I'd love to look into it.

[mohebmithani]

Hi @manuzope @jonesphillip can i take this as part of hacktoberfest issue?

[getsantry]

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

[Dhrumil-Sentry]

@scari @mohebmithani Thanks for your interest in this enhancement.

Recently Sentry released new issue states and transitions (Please see the changelog here)

There is no "Ignore" action now, it's "Archive" and the default behavior is that Sentry monitors Archived issues for any escalations and changes the state to "Escalating" accordingly.

The aim is to allow users to feel free to archive issues knowing Sentry has their back without needing to specify any count-based thresholds.

With this in mind could you please share some context on whether you'd still appreciate more granular controls in Slack and why you prefer "Archive until xyz" over the new behavior 🙏

cc @rachrwang @therealarkin

[mohebmithani]

@scari @mohebmithani Thanks for your interest in this enhancement.

Recently Sentry released new issue states and transitions (Please see the changelog here)

There is no "Ignore" action now, it's "Archive" and the default behavior is that Sentry monitors Archived issues for any escalations and changes the state to "Escalating" accordingly.

The aim is to allow users to feel free to archive issues knowing Sentry has their back without needing to specify any count-based thresholds.

With this in mind could you please share some context on whether you'd still appreciate more granular controls in Slack and why you prefer "Archive until xyz" over the new behavior 🙏

cc @rachrwang @therealarkin

@Dhrumil-Sentry Thankyou for the reply. I think Archive makes more sense and that also solved the initial problem raised in this issue. I don't think it needs more enhancement as of now.

[kthsieh]

@Dhrumil-Sentry our team has a bit of trouble managing status at the issue level rather than the event level. There are a few reasons for this:

• We have an "on point" engineer who is monitoring errors in production, and whoever is on point rotates week to week. We want the on point engineer to be able to mark that he has triaged a given event. If the on point engineer assigns it to himself, he is assigning the issue, so if the issue pops up again in a few weeks when he is no longer on point, it can be confusing to see that the event/issue was already assigned to someone else. If he ignores/archives or resolves it, we're worried we're not going to get notifications if it happens again. Additionally, early on, I didn't love Sentry's default fingerprinting, so I implemented a custom fingerprint. It works okay for the most part, but sometimes we'll get different events grouped together that aren't really the same issue.
• We have "staging" instances where we do QA. Every engineer is responsible for triaging errors caused by the instance they're testing on. Similarly, different events from different instances get grouped into the same issue, and it can be confusing as to how we should mark it as triaged.

So I guess what we really want is status at the event level. But in lieu of that, if we can archive for a day, it allows us to get kind of close to what we're looking for, because it allows us to mark an even as triaged, and even stop getting events for that issue for the day, but if the issue pops up again the next day, it still shows up. The reason I'm not confident in the "escalating" feature being sufficient is that we're a B2B app, not a B2C app, so we have relatively few users, and any error could potentially be really bad, not just the fact that an error is happening frequently.

[Dhrumil-Sentry]

@kthsieh Thanks a lot for the detailed feedback

This item is in our backlog and we'll keep this issue updated once we know more about timelines. We're looking into how we can improve our Slack experience and we'll keep this request in mind.

Additionally, early on, I didn't love Sentry's default fingerprinting, so I implemented a custom fingerprint. It works okay for the most part, but sometimes we'll get different events grouped together that aren't really the same issue.

@kthsieh we'd love to hear more about this 🙏 - Would you be up for a quick chat about this to discuss more?

[kthsieh]

@Dhrumil-Sentry Regarding the fingerprinting, that was years ago, so I don't remember the details anymore, and I never tried going back to the default fingerprinting. Is there a way I could test it out on existing events rather than making a code change to change fingerprints on new events?

[Dhrumil-Sentry]

@kthsieh Thanks for the response, I don't think there's a way to test grouping changes for existing events today

@rachrwang @brianthi a relevant question about testing grouping changes

[ceorourke]

We've released new Slack alerts that have updated archival options, you can read more about the changes here.