ash icon indicating copy to clipboard operation
ash copied to clipboard

Static defaults for array embedded resource attributes cause a cryptic compile error.

Open jimsynz opened this issue 3 months ago • 3 comments

Code of Conduct

  • [x] I agree to follow this project's Code of Conduct

AI Policy

  • [x] I agree to follow this project's AI Policy, or I agree that AI was not used while creating this issue.

Versions

erlang 28.1 elixir 1.19.0-otp-28

Operating system

macOS 26.0.1

Current Behavior

Given a resource with an array embedded resource and static defaults:

attribute :channels, {:array, MyApp.Channel} do
  default [%{name: :web, suppressible: false}, %{name: :email, suppressible: true}]
end

The app fails to compile with the following compilation error:

== Compilation error in file lib/my_app/notification_type/assignment_posted.ex ==
** (ArgumentError) cannot escape #Reference<0.96162257.3960733698.139143>. The supported values are: lists, tuples, maps, atoms, numbers, bitstrings, PIDs and remote functions in the format &Mod.fun/arity
    (spark 2.3.5) lib/my_app/notification_type/assignment_posted.ex:1: Spark.Dsl.__before_compile__/1

This is caused by the create action on the MyApp.Channel being called at compile time via a bulk create resulting in the following extra metadata:

        __metadata__: %{
          :selected => [:name, :suppressible],
          {:bulk_create_index, #Reference<0.910774993.731906049.251376>} => 1
        }

this metadata is on the two created records which are trying to be saved as the default value of the attribute entity on the resource.

This change was caused by efcf04748e327e6ffa5e8b29705e8c414775b4a5 AFAICT.

The user has been advised to use the 0-arity function version of defaults so that the resources are created when the :create action is called on the parent resource, rather than at compile time.

I am opening this bug to track that there is a compile error that is very difficult for a user to debug and not the fact that the behaviour has changed, because I think the old behaviour was probably wrong.

My suggested resolution is to remove the creation of default embedded records at compile time and emit an error.

Reproduction

No response

Expected Behavior

No response

jimsynz avatar Oct 16 '25 22:10 jimsynz

Two fixes here, one simple one more complex.

  1. we probably should check if the cast value can be unquoted, and if not, wrap the original value in a function
  2. that ref there was an unintentional change and we should fix that. I'll do this one and leave the issue open for the other one.

zachdaniel avatar Oct 17 '25 01:10 zachdaniel

So this should stay open?

jimsynz avatar Oct 17 '25 02:10 jimsynz

it should indeed.

zachdaniel avatar Oct 17 '25 02:10 zachdaniel