Raygun Feature Request

Feature Request

Ignore errors based on regex

Current Status:

Will not add

Votes:

29


Avatar

Stefan Kip

We've got many exceptions starting with 'HttpRequestValidationException: A potentially dangerous Request.Form value was detected from the client', caused by spambots. I'd like to be able to ignore errors starting with 'HttpRequestValidationException: A potentially dangerous Request.Form value was detected from the client', so an option to add filters based on regex would be ace!


Avatar

drgrieve

Posted on
Dec 16 2013

Also please let us config this via web.config - we are using raygun for many applications so logic for filtering out random 404's by bots should be easily transferable.

Avatar

DerangedMonkey

Posted on
Sep 05 2014

Please add support for this to the Javascript client, a simple function named shouldSend(error) or something similar which expects a boolean result to determine if should actually send that error.

Avatar

Dekian Animal

Posted on
Jul 03 2015

I see it has been awhile since this thread was updated. I am wondering if there is a solution to this yet? I also get a lot of Potentially Dangerous attempts I would love to simply suppress.

Avatar

simond

Posted on
Jul 03 2015

+1 Would love this feature too.

Avatar

rizalp

Posted on
Feb 05 2016

Any update on this feature request?

Avatar

Raygun

Jason Fauchelle

Posted on
Feb 11 2016

Most Raygun providers include a feature to examine messages before they are sent, and then cancel the send if you don't care about them. This is useful for exceptions that you know aren't going to be solved, and don't want them to eat any of your monthly Raygun exception limit.

Here is the documentation for doing this with the JavaScript provider: https://raygun.io/docs/languages/javascript#callbacks

And here is the documentation for Raygun4Net (This is for ASP .Net. Other .Net platforms have different instructions): https://raygun.io/docs/languages/net/asp#modify-cancel-message

Raygun4Net also has the option to ignore exceptions based on status code, e.g. 404: https://raygun.io/docs/languages/net/asp#exclude-status-code

Let us know if you can't find the documentation for this feature for a specific platform.

As you will see, this feature works by providing a callback function to contain your cancel message logic, rather than providing a regex to the provider. This allows you to write any logic you want, and examine any parts of the message to determine if a message should be cancelled. You could certainly use regular expressions within your cancel logic.

If you were looking for a way to set up ignore rules in the Raygun app, rather than via the provider in your code, this is something we do not currently have. We might provide a way to do this from the app, but don't have an estimate of when.

-Jason Fauchelle

Avatar

Alec

Posted on
Feb 12 2016

It's not ideal to change app code and redeploy just to categorize/skip errors. In many cases it's preferable to quickly address in the Raygun site instead.

Avatar

Dennis van de Hoef

Posted on
Feb 12 2016

I have to join Alec.

With one addition: we what to ignore errors, but not hide them completely from our statistics (which happens when we don't push them to raygun). We also might want to fix them on a later point (2/3 months) and the could use the info from the last months, without activly having seen the error the last months.

Avatar

Yosan

Posted on
Aug 29 2016

Hi there,

Thank you for your feature request. You can now ignore errors based on certain rules with our inbound filters feature. This feature allows you to filter out incoming crash reports if they match certain rules.

For your particular example, you can use the 'Message' filter to filter out incoming crash reports where the error message starts with or contains 'HttpRequestValidationException'. You can read more in our documentation here: https://raygun.com/blog/2016/08/filter-inbound-crash-reports-by-http-hostname/

At the moment, we're not looking at ignoring errors based on regex due to its unbounded nature ( http://stackstatus.net/post/147710624694/outage-postmortem-july-20-2016 )

Thanks again for the suggestions and comments!

Kind regards,

Yosan