Zach Daniel

That is a really good question :). My instinct tells me `:trivial | :low | :medium | :high | :huge`. Then we need to determine what exactly each one means...

I think that `complexity do` block in the API would just be for configuring the various rules around what the complexities entail. A simple example would be something like ```...

Let's start with the numeric values. We can always map the names to values, e.g `huge = 100_000`.

Sounds great! We can start w/ a PR just for specifying complexity, and then we can figure out a complexity analyzer from there.

Also, @kyle5794 we should do this in Ash core, since any interface would want to use this.

This has been stale for a while, and I'm more keen to believe that these rules should potentially end up in the api extensions at this point.

This would essentially just amount to going to every place where we do `Ash.Error.to_error_class` and passing in an extra string, and then accumulating those strings (in the case that we...

So the ultimate idea is that "more context on errors is better". The difficult thing in Ash is that the stacktrace is often practically useless because it is all generic,...

Yeah, this one is very strange... I haven't been able to figure out why this is the case but only sometimes.

Okay, so the problem here is that in some cases, so as not to induce an unnecessary compile-time dependency, we do some magic 🪄. https://github.com/ash-project/ash/blob/main/lib/ash/dsl/extension.ex#L1296 In one of my personal...