Ash.Type.Tuple Enumerable not implemented
I have an attribute of type
:tuple
defined like this:
When I create an instance of this model
I get this error
Is this expected? Am I doing something wrong?45 Replies
Okay, managed to get the stacktrace by calling
Splode.ErrorClass.error_messages
on the UnknownError, and it seems to happen here:
https://github.com/ash-project/ash/blob/v3.5.7/lib/ash/type/tuple.ex#L158-L159GitHub
ash/lib/ash/type/tuple.ex at v3.5.7 Β· ash-project/ash
A declarative, extensible framework for building Elixir applications. - ash-project/ash
I guess it should use
list
instead of value
there? The one defined at 155?
I'm testing the fix and opening a PR
okay, so that worked, but then it fails loading the struct from postgresπ₯²this is a new type and while I tried it w/ storage in my personal use case I only used it for an argument
If you can PR a test showing the issue and the fix you have so far I can review
I think I have the loading side working, will push a PR soon and we can review if it makes sense!
Awesome thank you π
Also pretty sure you already earned a pink name didn't you? I'll grant it now.
hahaha, thanks, I'm not sure yet
@Zach Daniel https://github.com/ash-project/ash/pull/2049
GitHub
fix: Tuple loader and serializer by MarceColl Β· Pull Request #2049...
The Tuple type had three bugs:
In dump_to_native the original tuple value was used instead of the tuple converted to a list. This caused Elixir to complain that Tuple doesn't have Enumerab...
@Zach Daniel there are some more problems actually.
For some reason this was working before but it's not working now. I have this action
However when I attempt to run it I get
I found that internally we were checking if
model
is the same as the previous one to detect if we need to update the updated_at
field, so I decided to set the updated_at
myself to see if that solved the issue by adding
And even though the query I see from ecto doesn't have a conditional on model
anymore, I still get the error
which is a bit confusing
This is the query I've seen for this
any ideas?Hmm....that would typically happen when it fails to cast to stored for example
Are any of the tuple types callbacks returning errors while that happens?
I tried debugging those by adding some logs in the callbacks for
cast_input
and cast_stored
but none of them returned errors that I could see
how do you usually debug this things? I'm not super experienced with elixir and my current testing setup is very rudimentary. I'm modifying things directly inside of deps/
to add IO.inspects here and there, then I mix deps.clean --build ash/ecto
and rebuildIt depends. In this case it's deep down in the belly of things so it's not the easiest
I'd typically have the packages cloned down and use path dependencies
So I can more easily work on the dependency code
makes sense
In this case Ecto does some stuff to hide error stack traces IIRC that makes it a bit tough to see what's going on
In the next Ecto version that will be configurable and I can likely make this better that way
For now I'll probably clone down ash_postgres and inspect where that error is probably coming from etc.
what I'm confused is that it complains about a filter, but there is no filter above on the given tuple
Yeah, that error is "synthesized"
Like it's getting a different error and turning it into that because it's usually that
ah, I see, that's why you say that I need to dig into what Ecto is doing
It's complicated π maybe you can open a PR w/ a test in ash_postgres?
I'm happy to investigate or give pointers
If you look in
data_layer.ex
there is a place where that invalid filter value is created
Like the error I mean
You could do some debugging there to see the original error
This one?
Yep!
That's without the forced updated_at, this one is with
Is it because fields is empty here, maybe?
Huh it's losing the constraints somehow?
I think this is a bug I'll have to look at
It's somewhere in our type casting logic and that is pretty hairy
Okay so next steps are to get a reproduction up I can play with
do you have enough with what I gave you above (my sample code?)
(okay, just discovered
dbg
with iex --dbg pry
, pretty nice)If you could add a test in ash_postgres that would be the ideal
I've got a lot on my plate today in addition to a cold π₯²
will try to do it later, gotta work now π
I didn't know what I was getting into by using the tuple type hahaha
π yeah its not your fault, I was rushing to get something ready for the AshAI demo and I never went back and closed the loop
I'm looking into it now
oh, I see you merged the PR above!
so I guess I'm officialy an Ash contributor ^^
sorry, I haven't had time to create a reproducing test yet π
between work and my daughter I haven't really found the time
its all good it should be fixed now
Or at least, I added some tests to postgres for whatever was going on, and made some type-related fixes in
Ash
that may have resolved the issue
but if you're still dealing with it LMKoh, so 3.5.11 should already have the fixes for the above issue?
will try later today
I believe so yes
upgraded ash and ash_postgres to latest version
They are now at 3.5.11 and 2.5.20 respectively, and I still get the same error
trying with a
deps.clean
first to see if it's a caching problem or smthdamn, alright
ah, right the problem for you was updating a certain way, nto filtering wasn't it
I'll take a look once I get a repro
I'll try to build a repro for you
trying with a deps.clean first to see if it's a caching problem or smthsame thing
you can take a look at the tests in ash_postgres, it should be pretty straightforward to add something there, and there is now a resource in the tests using the tuple type
the repro should be in
ash_postgres
right?
perfect, yeah, was checking your commit from yesterday
@Zach Daniel I cannot reproduce at all :doublefacepalm:π
In your repro, you're up to date on all the relevant packages?
ash
, ash_postgres
, ash_sql
?
yes
It looks like its an issue doing an atomic update
I've created the following test trying to replicate as much as possible the situation in ash_postgres
but it passes π
Try doing this:
Actually, what does that
:update
action that gets called the second time around look likein my case it's
defaults [:update]
in the Post model from ash_postgres it's
OH
if I change my update implementation for that one it also passes
so maybe the require_atomic? false in the update changes things (since primary? is set by the default)
that's why it passes in the test
yes, if I create another
and then update the change to use that one
it fails in ash_postgres with the same error
another interesting thing, it doesn't seem to happen with the tuple you created
that one works well (maybe because it's a custom type isntead of a literal tuple?)GitHub
chore: Create reproduction test of tuple Invalid filter value by Ma...
Contributor checklist
Bug fixes include regression tests
Features include unit/acceptance tests
so it seems that it is caused by calling another action that is not atomic? on a literal tuple attribute
Im wondering if I should be calling a nested action like this or not, is this expected? Or should I be doing
Resource
|> Ash.Query.filter(id == ^record.id)
|> Ash.bulk_update!(:update, %{model: new_model})
like you say?
I don't have time right now to reduce the test even more, hopefully it's a good starting point for further exploration
Perfect, I'll look into it π
Thanks for the repro
for now at least I'm unblocked π