[FEATURE REQUEST] Allow ignoring errors

[00dav00]

In other error handling platforms you have possibility to ignore an error (or group of errors) that you don't necessarily want to stop raising but would prefer not to receiving notifications for.

They idea would be to have something like the Ignore button I added in the screenshot.

After ignoring an error or group of errors, they will continue to appear in your dashboard, but you won't receive notification for them any longer.

How do you feel about adding support for this feature? With some guidance I would be glad to implement this since we do have some cases in our company were this can be helpful.

[burnettk]

thanks for raising this, @00dav00 , and re-raising it, @2called-chaos . yes, this does seem like a useful feature, especially if you don't have the ability to easily change the client code to filter on that side. perhaps consider the term "Mute" for that button? Would that be a better metaphor? But yes, a pull request would likely be accepted here.

[stevecrozz]

Are you potentially looking for a way to control notices without interaction? We have a configuration called ERRBIT_NOTIFY_AT_NOTICES which controls whether you receive notifications for every notice or only on, for example, the 1st, 50th and 500th occurrence:
ERRBIT_NOTIFY_AT_NOTICES=[1,50,500]

[goetzc]

I think the main idea here is to be able to silent or ignore a specific error from within the GUI. ERRBIT_NOTIFY_AT_NOTICES is nice but affects all errors in a specific project.

[stevecrozz]

Can we describe the particular use case a bit more and ? My understanding is that we're describing a situation like:

• ERRBIT_NOTIFY_AT_NOTICES=[0] (notify for every notice)
• User is getting too many notices for a particular error and is getting annoyed
• User doesn't want to change the notice behavior for all notices (can we dig into why not? what is so special about this notice?)
• User can't or doesn't want to change the client to stop sending notices to Errbit
• User wants Errbit to behave normally, but stop all future notifications

A couple more questions:

• If you mute a problem, can it be unmuted?
• Where do we store the mute bit?
• Is it permanent? or a temporary mute?

[00dav00]

Hi @stevecrozz , the questions you posted seems quite relevant, let me try to answer them.

User doesn't want to change the notice behavior for all notices (can we dig into why not? what is so special about this notice?)

In the case we experienced we wanted to track the error instances. That said, after a few hundred notifications it became annoying and without the bandwidth to deal with it at the moment we had to choose to ignore it since there was no option to "mute" it. That was fine since we already had some instances of the error, but the ideal scenario for us would have been only stop the notifications.

If you mute a problem, can it be unmuted?

That is an excellent question, I would say yes, mute flags should be able to be removed

Where do we store the mute bit?

To answer this I would have to dig into the code, which I haven't done yet, but suggestions from people with more context on the project could be beneficial here.

Is it permanent? or a temporary mute?

I would start with a temporary mute, like mute_until and then if the functionality seems like something worth adding, implement a permanent mute option. In the use case I experienced the temporary mute would have been the most useful one.

Please let me know WDYT, I' happy to discuss this further with people more involved in the project to see the viability of it and put some hours into it's implementation

[stevecrozz]

Thanks @00dav00, this use case makes sense to me. I have one other idea that I'd like to offer. Whenever possible, I try to avoid adding new GUI features because they add up over time and clutter the otherwise very simple interface. Is there any automated solution you can imagine that would suffice? For example, what if Errbit supported some kind of exponential backoff on notifications like, send notifications according to a user-defined expression?

Idea: ERRBIT_NOTIFY_AT_NOTICES='fn: Math.sqrt(n).floor > Math.sqrt(n - 1).floor'

This example expression would send notices at perfect squares: (ie 1, 4, 9...), but any Ruby expression could be used.

This way you could define exactly the notice behavior you want without user interaction.

Please think it over if something along these lines could work. If this really isn't good enough and you need a GUI control, then we can do it. In that case, I do prefer your idea of mute_until. I definitely want to prevent this from becoming a permanent mute because that goes against one of Errbits principles of preferring to filter on the client side. So I'm thinking a UI control that says 'Mute' or 'Snooze' or something like that. And when you click the button you'd get a couple of options like '1 hour, 8 hours, 48 hours'

[00dav00]

Hi @stevecrozz , that looks like a nice shortcut to config ERRBIT_NOTIFY_AT_NOTICES values.
Personally, I would prefer to be able to mute an specific errbit, that said I see your point about avoid adding to many things into the UI.
Thanks!

[goetzc]

Idea: ERRBIT_NOTIFY_AT_NOTICES='fn: Math.sqrt(n).floor > Math.sqrt(n - 1).floor'

Although that is useful (and possibly a security vulnerability to have arbitrary code as an environment variable?), Insee the use case for the GUI option is when not having access or not having the knowledge to manipulate the Errbit configuration, or even affording the (down)time. Also this would affect every single project and issue.

When the desire is to mute a specific short duration notice, I see a GUI option as the most appropriate solution. Something similar to other servers like Sentry that have such options, which are useful:

[stevecrozz]

I'm ok with this idea and I'll be happy to review a PR. If you want some guidance, I'd say give it a look and open a PR with a rough start and leave questions wherever you have them. You are welcome to approach it however you want, but it might be nice to start with a rough draft of the UI. I think the back end should be pretty simple. Here's a list of what I'd want to see in this feature, let's see if you agree:

Front end:

• Ignore until some time has passed, maybe hardcode 3 intervals to start with. Whichever sound convenient to you (ie 1 hour, 12 hours, 48 hours), adds an ignore for a problem
• Stop ignoring, clears the ignore for the problem
• Status of ignore, is the problem currently being ignored or not? If so, until when?

Back end:

• Check ignore status before sending a notification. If ignore_until is set and in the future, do not send a notice.

@00dav00 Would you update this issue with either these requirements, or whatever requirements you think are better? And please let me know if you need anything! Thanks for raising this request.

[sahglie]

This is a feature that I've needed for a while now and I've given it a shot with PR #1547. I've gone with the terminology "mute" (instead of ignore) as I think that more clearly indicates what the feature does: mutes notifications. Happy to revise or tweak the PR based on any suggestions.