spacebat
Exceptions in Ash datalayer have unhelpful stack traces
A number of times I’ve run into some error or other while developing in ash, the exception is printed along with a stack trace but it’s all library and framework stack frames. The message will be something like “Input Invalid” and “widget_id: has already been taken” but it’s not clear without a bunch of IO.inspect debugging what part of the application code is calling the library in a way that causes the error.
I know that Ash runs queries in a separate processes and that’s probably the stack trace that I’m seeing. The way that Elixir apps function, this is a common pattern. Is there a generally accepted approach to dealing with this other than manually instrumenting code with debugging output?
Most Liked
zachdaniel
So there are a couple things we can do to help with this. The first one is providing more bread crumbs in our error messages. Additionally, you can try extending the backtrace depth when your app starts
:erlang.system_flag(:backtrace_depth, 100) in your application start.
def start(_type, _args) do
:erlang.system_flag(:backtrace_depth, 1000)
...
end
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








