lardcanoe

lardcanoe

as always, thank you for responding!

i went to get some timing for my code on Ash 2.0, and when I switched back to the V3 stuff and recompiled I got a deadlock. After a few hours of narrowing down the culprit, it seems to be specifying the domain on an embedded resource. If I wipe out my _build folder and compile without the domain specified on the 2 embedded resources, things compile, but then obviously the forms that use those fail since a domain isn’t specified (even though the parent resource has a domain set!).

Once compile fails, I can go back to main resource, change the embedded attributes to be {:array, :map}, and compile works. i can then revert back to the embedded type {:array, MyEmbeddedResource} with a domain specified in it, and compile now works.

I don’t know the erlang/elixir compile process well, but I point this out because people should probably wipe out their _build folder before thinking things are ok!

happy to move triaging this to another location, discord? but i am kind dead in the water with ash 3 right now.

This makes no mention of the embedded resources, but they are it afaik:

== Compilation error in file lib/my_app/scheduling/main_resource.ex ==
** (CompileError) deadlocked waiting on module MyApp.Scheduling
    (spark 2.1.16) lib/spark/dsl/extension.ex:128: Spark.Dsl.Extension.persisted!/3
    (spark 2.1.16) lib/spark/dsl/extension.ex:282: Spark.Dsl.Extension.get_opt_config/3
    (spark 2.1.16) lib/spark/dsl/extension.ex:240: Spark.Dsl.Extension.fetch_opt/4
    (spark 2.1.16) lib/spark/dsl/extension.ex:208: Spark.Dsl.Extension.get_opt/5
    (ash 3.0.0-rc.18) lib/ash/actions/helpers.ex:181: Ash.Actions.Helpers.add_actor/3
    (ash 3.0.0-rc.18) lib/ash/actions/helpers.ex:111: Ash.Actions.Helpers.set_opts/3

== Compilation error in file lib/my_app/scheduling.ex ==
** (CompileError) deadlocked waiting on struct MyApp.Scheduling.MainResource
    (elixir 1.16.2) src/elixir_fn.erl:17: anonymous fn/4 in :elixir_fn.expand/4

Compilation failed because of a deadlock between files.
The following files depended on the following modules:

  lib/my_app/scheduling/main_resource.ex => MyApp.Scheduling
            lib/my_app/scheduling.ex => MyApp.Scheduling.MainResource
0
Post #12
zachdaniel

zachdaniel OP

Creator of Ash

There is no need to specify a domain for embedded resources. Does omitting that resolve the issue?

0
Post #13
zachdaniel

zachdaniel OP

Creator of Ash

Sorry, just read further. Okay, this is a bug in ash_phoenix then. Will fix!

0
Post #14
zachdaniel

zachdaniel OP

Creator of Ash

Okay, so I’ve just pushed what might be a fix up to ash_phoenix main. I can see places where we weren’t threading the domain down to nested forms that were created. I’ve cleaned all of those up, but don’t have time to test it myself until tomorrow. If you could please try out main

{:ash_phoenix, github: "ash-proejct/ash_phoenix", override: true} and see if that resolves your issue, that would be great.

If it does, let me know and I will cut a release first thing. If it doesn’t, please log an issue on the ash_phoenix GitHub repo.

It makes sense that the embedded resource declaring a domain would cause a circular compilation issue, but I hand’t thought of it before. I will add a compile time error tomorrow preventing the domain option from being present on embedded resources. The basic problem is domain -> resource -> embedded resource -> domain.

In Ash, resources have compile time dependencies on types, and not relationships. Since :embedded resources are treated as types, that causes this issue.

1
Post #15
lardcanoe

lardcanoe

Fixed! Thank you so much!

(I had a temp fix of just defining a domain for embedded resources :person_shrugging:)

Recompile times seem ok now. I editted a bunch rapidly to see what happens and they are back to at least feeling as long as Ash 2.

mix xref graph --format cycles is basically the same as from Ash 2.0

Just about every (or maybe every) resource has a cycle of length 3:

lib/my_app/domain/resource_a.ex
lib/my_app/domain.ex
lib/my_app/domain/resource_a.ex

Nothing can be done about that, right? Seems expected, and not sure it even matters.

0
Post #16
zachdaniel

zachdaniel OP

Creator of Ash

Actually, that is interesting… I think I can make that better :slight_smile: Will let you know.

0
Post #17
zachdaniel

zachdaniel OP

Creator of Ash

Actually, I’m not seeing those same cycles. Do you have things like anonymous functions in your resources that call functions defined in your domain? Would be worth looking into :slight_smile: Perhaps lets start a new topic for it though.

EDIT: @lardcanoe maybe try mix xref graph --format cycles --label compile? runtime cycles are not really a problem.

0
Post #18
zachdaniel

zachdaniel OP

Creator of Ash

Setting domain on an embedded resource is now a compile error, to prevent folks from accidentally having a confusing circular dependency.

0
Post #19
arcanemachine

arcanemachine

Reading about your experience makes me feel like the RC is pretty stable.

I’ve been waiting to take Ash for a proper spin for quite a while! I kicked the tires a bit when Ash v2 was newer but other projects ended up taking up all of my time.

1
Post #20
lardcanoe

lardcanoe

OH! Very cool. No cycles. Did NOT realize that tool had a distinction between runtime and compile. Thank you!

0
Post #21