Static defaults for array embedded resource attributes cause a cryptic compile error.
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
Two fixes here, one simple one more complex.
- we probably should check if the cast value can be unquoted, and if not, wrap the original value in a function
- 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.
So this should stay open?
it should indeed.