-
Notifications
You must be signed in to change notification settings - Fork 527
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
resolve_type second parameter is just some other resolved object? #1149
Comments
Additional debugging shows that for every item, resolve_type is called with a different path in second argument (each path element has {name, partent_type.identifier}):
So the calls to resolve_type pass Execution context with very weird paths:
(not that for Target with index 2, it is not even in the path - Target with index 1 is) |
Hey @marcinkoziej, that is definitely a bit strange. Traditionally the reason we pass in the env has more to do with making the schema available and the context available, I don't know that the other values in that struct have been validated in this situation. Possibly there is some data leaking over from the execution flow. Let me look into it. |
Addresses issue absinthe-graphql#1149. module `Absinthe.Phase.Document.Execution.Resolution` walks the result tree and tracks `path` using a function parameter. At the same time, a `Resolution` struct is passed, which `path` field is not consistently tracked. The problem manifests itself in bogus Resolution path passed onto `resolve_type` function as described in function absinthe-graphql#1149. The reason for not updating the resolution.path in the walk process can be explained by comment of @benwilson512: `Traditionally the reason we pass in the env has more to do with making the schema available and the context available, I don't know that the other values in that struct have been validated in this situation.` Perhaps path parameter was used in the beginning and later resolution paramter was added, but not used to track current tree walk in it's path field. Nevertheless, the resolution is passed on to user code - into `resolve_type(value, resolution)` callback, which might use path to understand the context of value (eg. what is the type of parent?). This PR fixes the bookkeeping of `resolution.path` field. I have not inspected the use of other field, I am not sure which ones would change during the value walk (`parent_type` maybe?). One could consider to just use `resolution.path` instead of `path` parameter - so there is not double bookkeeping of this value. This is up to maintainers to decide, I did not make such a change.
Hi!
Reporting a potential bug:
Environment
Erlang/OTP 24 [erts-12.0.3] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] [jit]
Elixir 1.12.0 (compiled with Erlang/OTP 23)
mix deps |grep absinthe
locked at 1.7.0 (absinthe) 566a5b55
locked at 2.0.2 (absinthe_phoenix) d3691892
locked at 1.5.8 (absinthe_plug) bbb04176
Client framework: GrapqiQL playground
Expected behavior
When resolving a list of interfaces, I expect that
resolve_type(object, env)
receives a second argument that contains information about parent/location of object in the graph - consistently for all items.Actual behavior
I have a problem when resolving type of a list of objects.
I have a following graph:
If you have a permission to see campaign (interface) as private campaign (object), you can also see the target (iface) as private target (object).
Target emails are only visible on private target.
In target interface definition, i want to check what the parent (campaign) was resolved to either
:public_campaign
or:private_campaign
(the :parent_type field)When doing a query like this:
When resolving all items in the target list for particular campaign, only the FIRST target is resolved as
:private_target
- and the resolve_type is given the object where I can match on:%{parent_type: %{identifier: :private_campaign}}
.The SECOND target receives something else as second argument - the
%{parent_type: %{identifier: :target_email}}
, which seems to be a child of FIRST target, not parent of SECOND one!This is quite confusing - is this a bug, or is it expected? If expected, how use a resolve_type supposed to use the second argument? What would be the use case?
Relevant Schema/Middleware Code
campaign type:
targets:
The text was updated successfully, but these errors were encountered: