thojanssens1
Error tracking tools and "let it crash" philosophy
In Elixir and Phoenix applications, we tend to let it crash when there is an error and can’t return a meaningful response the user.
E.g. a controller action may try to fetch a user by id Users.get_user!(user_id) from a route param, and if not found, Phoenix.Ecto lib allows to convert the Ecto.NoResultsError error to a 404 http not found page.
However, when using an error tracking tool such as AppSignal, Sentry, etc. couldn’t that lead to many useless error reports, bloating the logs, e.g. in cases where there are bots frequently trying to requesting URLs with wrong route params?
What about DDoS attacks against URLs with wrong route params, won’t that lead to a lot of resource consumption because of mass api calls to the chosen error tracking systems?
Most Liked
NobbZ
Assuming correct configuration, sentry or app signal wont see those errors, as they have been handled by other means.
Those error trackers/aggregators are to give you insight into errors that haven’t been handled, or that have been sent to the tracker explicitely.
Popular in Questions
Other popular topics
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
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








