moxley
`not found in: nil` exception after Ash upgrade
I upgraded to the latest Ash (3.4.66 → 3.5.8), and one of my AshGraphql tests is failing with this error:
08:24:51.258 request_id=GDwNw_x3uKJp7GcABxLB [error] cc719ddb-f52a-498e-97e7-def0d60a6290: Exception raised while resolving query.
** (Ash.Error.Unknown)
Bread Crumbs:
> Exception raised in: GF.Events.Participation2.read
> Exception raised in: GF.Events.Event2.read
Unknown Error
* ** (KeyError) key :to_tenant not found in: nil
If you are using the dot syntax, such as map.field, make sure the left-hand side of the dot is a map
(ash 3.5.8) lib/ash/policy/check/expression.ex:3: Ash.Policy.Check.Expression.try_strict_check/3
(ash 3.5.8) lib/ash/policy/policy.ex:183: Ash.Policy.Policy.fetch_or_strict_check_fact/2
(ash 3.5.8) lib/ash/policy/policy.ex:431: Ash.Policy.Policy.handle_constants/2
(ash 3.5.8) lib/ash/policy/policy.ex:404: Ash.Policy.Policy.handle_constants/2
The line of code in Ash that raises the error is this: ash/lib/ash/policy/filter_check.ex at main · ash-project/ash · GitHub. subject is nil.
This is for an AshGraphql test.
This appears related to multitenancy. GF.Event.Event2 has a multitenancy block and a tenant database column, but GF.Events.Participation2 doesn’t.
In the error breadcrumbs, you’ll see two resources mentioned. The root resource being queried is GF.Events.Event2. It appears to be the has_many :attendees relationship to GF.Events.Participation2, because when I remove the attendees GraphQL field from the test, the error is gone. In this test, the actor should not have access to the attendees, but that wasn’t a problem before. It just returned an empty list for that case.
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #hex
- #performance











First 10 of 18 Posts
zachdaniel
subjectshouldn’t ever be nil at that line (which is why we don’t defensively use something likesubject[:to_tenant]. Is there more stacktrace available than just those lines? are your other Ash related dependencies updated to the latest as well?moxley
Here’s the whole stacktrace:
Yeah, all the Ash related dependencies are up to date:
moxley
I also noticed that if I change the test so that the actor has access to the
:attendeesrelationship, the error still happens.moxley
I further isolated the conditions that cause the error. Here’s the GraphQL query now:
When there’s a
filter, the error happens. When I take it out, there’s no error.moxley
And further still:
It’s that filter on the member resource (
Event2→ has_many :attendeesParticipation→ belongs_to :memberMember2)zachdaniel
Okay that helps. I think it’s a small plumbing error in the filter authorization code.
moxley
Then finally, in the test, the actor doesn’t have policy access to the member
statusattribute. When I update the actor to be able access it, the error goes away.zachdaniel
Okay, so the strange thing is why the existing field policy tests aren’t hitting that case
I’ve tried a similar formulation to what you have in various forms at the resource level. Can you reproduce this issue if you runt he corresponding Ash request? Something along the lines of
query |> Ash.Query.load(attendees: Ash.Query.filter(Attendee, member.status == :active))zachdaniel
So I haven’t been able to reproduce this yet in my testing. If you have any way of reliably reproducing that would be great so we can of course get this covered by our authorization test suite. IIRC we have some field policy testing in
AshGraphql, perhaps it could be reproduced there? I’ve got to step away for the rest of the day, but I’ve pushed up a change tomainto normalize the underlying data structure in more of the callbacks which may resolve this issue. A release will go out next week or the week after (I’ve just merged combination query support which may need some time to bake).moxley
Yes, that reproduces the error: