I am using Sentry 8 from Hex sentry — sentry v8.0.6 and I see it reports lots of errors that are perfectly normal for Phoenix apps, e.g.
%Ecto.NoResultsError{} happens when someone mistypes an id in the URL. It is converted properly to 404.
%Plug.CSRFProtection.InvalidCSRFTokenError{} happens always when session ends and user tries to back-navigate. It is properly handled in a default setup.
%Plug.Conn.InvalidQueryError{} when someone mistypes a URL.
%Phoenix.NotAcceptableError{} happens when someone tries to use wrong content-type.
All of those are handled in the default configuration and properly converted to a correct HTTP error.
Should I simply add all Plug events to Sentry event filter? At least those that have designated HTTP error code?
The type of error you list there are things we generally check for in our controllers and/or service layer. In any case these are not the types we tend to let leak to the outer layer, so we do something with them. We do indeed have the occasional invalid JSON posts when a crawler passes by, but no filters at all.
Our strategy towards Sentry is to handle/catch every error in our app, Sentry should be silent.
1 Like
To necro this thread somewhat, @jeroenbourgois how are you handling this in the controller / service layer out of interest?
Well to be honest, while re-reading the OP question, I have to say some might be valid to just let pass… But the reason we want our Sentry to be silent is because errors that occur there should be unexpected. If you have error occur constantly then it will make you ignore Sentry, which is not what you want.
For the first one (%Ecto.NoResulsError{}) I would just catch that in the controller where you get the resource and show a flash message or redirect alltogether. The second one might something you can just fail on its own, but the last two again I would handle in the controller and either show an appropriate flash message.
