tomekowal
I am using Sentry 8 from Hex README — Sentry v13.2.0 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?
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Bringing learning, work and compliance together since 1987.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #ai
- #phoenix_html
- #elixirconf-us
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Producing high quality Elixir screencasts since 2017.
Enabling companies to succeed by building software people love.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 3- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
jeroenbourgois
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.
Rodeoclash
To necro this thread somewhat, @jeroenbourgois how are you handling this in the controller / service layer out of interest?
jeroenbourgois
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.