Add an option to ignore an entire exception

[kennethito]

I see that you can filter out parts of an exception, but I was wondering if there was a way to selectively ignore and not notify an entire exception.

Use case. The version of cowboy we are on generates an exception for certain characters in urls via :cow_uri.urldecode/2 . We've had millions of these in the last week due to people probing our site and blew through our honeybadger plan. I'm looking for a way to ignore or rate limit these exceptions.

[joshuap]

@kennethito you can ignore the error in the Honeybadger UI and we'll stop alerting you about it, but I don't think we have a way to completely ignore the error in the client, which would be better (since then it wouldn't be sent to our servers at all). @sorentwo we don't currently have a solution for this that I am missing, do we?

[kennethito]

Gotcha.

@joshuap Ignoring the error in the Honeybadger UI doesn't prevent the error from consuming your quota correct?

[sorentwo]

@sorentwo we don't currently have a solution for this that I am missing, do we?

No, there isn't any way to declare that certain exceptions should be ignored on the client side currently.

[joshuap]

Ignoring the error in the Honeybadger UI doesn't prevent the error from consuming your quota correct?

Correct, they do not consume quota!

In any case, I think this is a feature we want to eventually add, so I'll leave this open to track it.

[sezaru]

Is this still a wanted feature? If I create a PR to support filtering out exceptions would it be considered to be merged?

[joshuap]

@sezaru yeah, I would like this feature. What kind of configuration API are you thinking? @sorentwo, do you have any thoughts on the best approach?

Here's how we do this in Ruby and JavaScript:

https://docs.honeybadger.io/lib/ruby/getting-started/ignoring-errors.html
https://docs.honeybadger.io/lib/javascript/guides/reducing-noise.html

[sezaru]

I was thinking about a very simple behaviour with a single filter/1 function that receives the Notify struct and the user can define its own logic to when and how he wants to filter the exception.

Thanks for the links, I just took a fast look at it and it seems that they allow more complex filter cases like by exception type, etc.

For my use case, only the behaviour described above is enough, but if it is desirable, I could simply have some already implemented adapters for that behaviour for each use case.

For example, an adapter that reads a config with the exception types they want to ignore and filters then, etc.

Do you have any better suggestion or something like that would do?

Also, one thing that would be nice to have as documentation is an explanation of how Honeybadger defines errors equality. As far as I know it its the error title plus the error stack trace, but maybe there is some other thing, knowing that would be great to the user who wants to use this so he can filter the messages in a more "fine-tuned" way.

PS. For my use case, I want to create a separated GenServer that will store a state with counters of how many each type of errors (defined as title + stack trace for now) was triggered in a time period, let's say a max of 10 errors in a 10 minute period, and each minute that counter would subtract one. Something like a rate-limit fashion per error type.

[joshuap]

Also, one thing that would be nice to have as documentation is an explanation of how Honeybadger defines errors equality. As far as I know it its the error title plus the error stack trace, but maybe there is some other thing, knowing that would be great to the user who wants to use this so he can filter the messages in a more "fine-tuned" way.

Oh yeah, our Elixir docs are lacking on this atm—I'm making a note about that. In the meantime, here's our Ruby guide on how we group errors (which is the same for Elixir by default). We support a number of custom fingerprint options in the Elixir client.

Regarding the API, I think the option to ignore errors with a Notice struct could work, but I'm less sure about naming the method/option filter/1, since we already have a number of filter config options which serve a different purpose. /cc @sorentwo @rabidpraxis