Zach Daniel

I believe there is all the necessary information in the `auth_controller` to handle any kind of successful auth or failed auth, and the `conn` is available there for redirecting and/or...

Ah, right. So that happens when you have `sign_in_tokens_enabled? true`, which allows auth to happen in the LiveView itself. You could potentially turn that off and then your auth controller...

We'd likely need a separate callback like `live_failure` since the first arg would be a socket and not a `conn`

🚀 Thank you for your contribution! 🚀

Thanks for the report! There is no harm in adding it to both places. I won't have time to do this in the near future, but PRs welcome 🙇

There is no way that I know of to do so easily, open to a task for it :)

Yeah, this is definitely an interesting issue. We don't actually currently validate the types and or values returned from calculations, primarily because it would add a non-trivial cost to do...

its important to communicate generated type information, like in `ash_graphql`, so we need to have the option.

I don't think it's really an option to remove, because non-nullability drastically simplifies client interfaces, it just has to be on the user to ensure that their calculation honors the...

The specific thing here is not necessarily relationships with `primary_key?: true`, it's *composite primary keys* that need to be supported.