Inconsistent behaviour between Ash.get and read actions, and Ash.load in context multitenancy (pg)
Ash.load(resource,[...], actor: user, tenant: company_id) works
Ash.get(resource, actor: user, tenant: company_id, load: [....]) doesnt work, same with custom read actions on resource
Is there some limitations with the context mulitenancy that i should be aware of? because i have struggled quite alot just loading relationships on resources, which should be one of the simplest things, but its not. I get wierd errors when i load with Ash.get or using custom read actions that there is not table like <UUID>.my_resource_table. It almost feels like it hits the wrong Repo or the wrong database. Im using two repos, but i just commented out the other repo from config and tried again, same error.
this is the error i get
any tips?
Solution:Jump to solution
@Zach Daniel ill mark it as solved, i dont have time to debug why it failed in the old project. Its working in the new project now.
12 Replies
Oh and yes i have tenant_migrations working and all other tests pass, just this little wierdo test that stumbles me, and it might be many other tests with similar issues too (i just keep on working on one test and fix it and then look for the next ...)
This is something i wouldnt dare give to any AI agent, because it will just use up credits af to just say "i decided to delete all the code and replace it with some much simpler code".. thanks AI .. no it doesnt help us .... i have tried some AI agent work on ash but its futile for complex stuff like this, where even I as as human can see inconsistency .. or am i human .. or a lizard .. who knows đŸ˜„
Are you on the latest versions of
ash
, ash_sql
and ash_postgres
?
Oh, interesting, two repos
Does that mean two separate databases?Its same database actually. Im just too lazy to create a new project and migrate to ash. So I have old ecto code and tests in one silo with its own old repo. It works actually
Yes 3.5 of ash and 2. Something of the others
I mean, latest version means completely latest version not just major versions
many fixes in minor/patch versions
I thought mix was smart and used the latest. But I see your polnt
Will check tomorrow
it depends, you want
mix deps.update ash ash_sql ash_postgres
just to be sure
often its something we've already fixed
49f7b9e2-c539-46c4-a518-8b556e6aa866.ash_supplier_invoice_lines
is that table supposed to exist?
ash_supplier_invoice_lines
is that table with a resource that has multitenancy?
I think this may in fact be something we fixed đŸ˜„Will do two things tomorrow. One update versions and two rip this out from the old code if its not fixed by update
đŸ«
Just LMK if updating doesn't fix it as otherwise its likely a small bug on our end
updated all dependencies
%{
"ash": {:hex, :ash, "3.5.34",.....
"ash_phoenix": {:hex, :ash_phoenix, "2.3.13",.....
"ash_postgres": {:hex, :ash_postgres, "2.6.15",.....
"ash_sql": {:hex, :ash_sql, "0.2.89",.....
still same issue. i will try to make a smaller application to replicate the issue and publish it on github
if you dont already know whats the problem ofc
hmm why is there is a two way requirement for repo config, both in config AND In the resources? or is config.exs repo config now optional? its a segway, just poking at it while creating the bug demo project
dam it works in another project .. then its specific to that other project... will see if i can compare them ....
:/ time to start 1. debugging . or 2. accepting the fact i need to start a completely new project only based on ash .. guess it will be the latter đŸ˜›

Solution
@Zach Daniel ill mark it as solved, i dont have time to debug why it failed in the old project. Its working in the new project now.
the learning is to isolate isolate isolate