-
Notifications
You must be signed in to change notification settings - Fork 529
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
Introspection query fails when using a prototype schema that defines types for use by directive arguments #1279
Comments
We're also experiencing this issue. Could this be related to custom schema directives not showing in in SDL as well? @benwilson512 We're happy to spend some time working on this, any chance you could provide some direction? |
I'm running into this as well. I've pared down the above example code a bit into a unit test that can be dropped into describe "introspection of complex directives" do
defmodule ComplexDirectiveSchema do
use Absinthe.Schema
use Absinthe.Fixture
defmodule ComplexDirectivePrototype do
use Absinthe.Schema.Prototype
input_object :complex do
field :str, :string
end
directive :complex_directive do
arg :complex, :complex
on [:field]
end
end
@prototype_schema ComplexDirectivePrototype
query do
field :foo,
type: :string,
args: [],
resolve: fn _, _ -> {:ok, "foo"} end
end
end
test "renders type for complex directives" do
result =
"""
query IntrospectionQuery {
__schema {
directives {
name
args {
name
description
type {
kind
name
}
defaultValue
}
}
}
}
"""
|> run(ComplexDirectiveSchema)
assert {:ok,
%{
data: %{
"__schema" => %{
"directives" => [
%{
"name" => "complexDirective",
"args" => [%{"type" => %{"kind" => "OBJECT", "name" => "complex"}}]
}
]
}
}
}} = result
end
end I'm not 100% sure on the return type for {
:ok,
%{
data: %{"__schema" => nil},
errors: [%{locations: [%{column: 9, line: 8}], message: "Cannot return null for non-nullable field", path: ["__schema", "directives", 0, "args", 0, "type"]}]
}
} |
@benwilson512 sorry to bother you but it would be great if you had any pointers for this issue. We currently cannot get introspection at all if the schema uses the |
any update on this? |
This fixes an issue when you have types declared in a Prototype (such as input_object input types for a directive). Previously type resolution would look on the Schema, but not the Prototype for the type definitions. You _could_ workaround this by duplicating your type definition into both the Schema and the Prototype. This makes me somewhat curious if there is a better way to fix this, in that the code that was trying to resolve the type here shouldn't be resolving it on the Schema, but rather on the Prototype 🤷. This seems to work though. Fixes absinthe-graphql#1279
I may have a fix for this. It fixes the test I included above. I haven’t tested it out with main...jeffutter:absinthe:recurse-prototype-type-resolution I’ll give it a more thorough test tomorrow and open a PR if it seems to work. |
Confirmed that code allows us to execute both the federation |
This fixes an issue when you have types declared in a Prototype (such as input_object input types for a directive). Previously type resolution would look on the Schema, but not the Prototype for the type definitions. You _could_ workaround this by duplicating your type definition into both the Schema and the Prototype. This makes me somewhat curious if there is a better way to fix this, in that the code that was trying to resolve the type here shouldn't be resolving it on the Schema, but rather on the Prototype 🤷. This seems to work though. Fixes absinthe-graphql#1279
This fixes an issue when you have types declared in a Prototype (such as input_object input types for a directive). Previously type resolution would look on the Schema, but not the Prototype for the type definitions. You _could_ workaround this by duplicating your type definition into both the Schema and the Prototype. This makes me somewhat curious if there is a better way to fix this, in that the code that was trying to resolve the type here shouldn't be resolving it on the Schema, but rather on the Prototype 🤷. This seems to work though. Fixes absinthe-graphql#1279
This fixes an issue when you have types declared in a Prototype (such as input_object input types for a directive). Previously type resolution would look on the Schema, but not the Prototype for the type definitions. You _could_ workaround this by duplicating your type definition into both the Schema and the Prototype. This makes me somewhat curious if there is a better way to fix this, in that the code that was trying to resolve the type here shouldn't be resolving it on the Schema, but rather on the Prototype 🤷. This seems to work though. Fixes absinthe-graphql#1279
This fixes an issue when you have types declared in a Prototype (such as input_object input types for a directive). Previously type resolution would look on the Schema, but not the Prototype for the type definitions. You _could_ workaround this by duplicating your type definition into both the Schema and the Prototype. This makes me somewhat curious if there is a better way to fix this, in that the code that was trying to resolve the type here shouldn't be resolving it on the Schema, but rather on the Prototype 🤷. This seems to work though. Fixes absinthe-graphql#1279
If submitting a bug, please provide the following:
Environment
Expected behavior
When using a prototype schema that defines directives as well as types used for the directives' arguments, the introspection query should succeed and return directives used by the schema as well as the argument types.
Actual behavior
The introspection query fails:
Poking around the schema (not the prototype schema) using
Absinthe.Schema.lookup_*
functions reveals that the directives resolve properly but looking up the custom argument types returnsnil
:iex output
Relevant Schema/Middleware Code
I really just copied the schemas from
type_system_directive_test.exs
.Prototype schema
Code
Schema
Code
The text was updated successfully, but these errors were encountered: