| Q | A
| ---------------- | -----
| Bug report? | yes
| Feature request? | no
| Version/Branch | dev-master
I have the following configuration:
Platform:
type: 'interface'
config:
description: 'Platform'
resolveType: '@=resolver("platform", [value])'
fields:
id:
type: 'ID!'
StripePlatform:
type: 'object'
inherits: [Platform]
config:
interfaces: [Platform]
isTypeOf: '@=isTypeOf("App\\Entity\\StripePlatform")'
Customer:
type: 'object'
config:
isTypeOf: '@=isTypeOf("App\\Entity\\Customer")'
fields:
id:
type: 'ID!'
platform:
type: 'Platform!'
throws this exception:
GraphQL\Error\InvariantViolation:
Interface Platform must be implemented by at least one Object type.
at vendor/webonyx/graphql-php/src/Type/Schema.php:472
at GraphQL\Type\Schema->assertValid()
(vendor/overblog/graphql-bundle/src/Definition/Type/SchemaExtension/ValidatorExtension.php:13)
at Overblog\GraphQLBundle\Definition\Type\SchemaExtension\ValidatorExtension->process(object(ExtensibleSchema))
(vendor/overblog/graphql-bundle/src/Definition/Type/ExtensibleSchema.php:54)
at Overblog\GraphQLBundle\Definition\Type\ExtensibleSchema->processExtensions()
(vendor/overblog/graphql-bundle/src/Request/Executor.php:147)
at Overblog\GraphQLBundle\Request\Executor->execute(null, array('query' => '{ customer(id: "1") { id platform { ... on StripePlatform { id } } }}', 'variables' => null, 'operationName' => null))
(vendor/overblog/graphql-bundle/src/Controller/GraphController.php:161)
at Overblog\GraphQLBundle\Controller\GraphController->processNormalQuery(object(Request), null)
(vendor/overblog/graphql-bundle/src/Controller/GraphController.php:121)
at Overblog\GraphQLBundle\Controller\GraphController->processQuery(object(Request), null, false)
(vendor/overblog/graphql-bundle/src/Controller/GraphController.php:90)
at Overblog\GraphQLBundle\Controller\GraphController->createResponse(object(Request), null, false)
(vendor/overblog/graphql-bundle/src/Controller/GraphController.php:61)
at Overblog\GraphQLBundle\Controller\GraphController->endpointAction(object(Request), null)
(vendor/symfony/http-kernel/HttpKernel.php:150)
at Symfony\Component\HttpKernel\HttpKernel->handleRaw(object(Request), 1)
(vendor/symfony/http-kernel/HttpKernel.php:67)
at Symfony\Component\HttpKernel\HttpKernel->handle(object(Request), 1, true)
(vendor/symfony/http-kernel/Kernel.php:198)
at Symfony\Component\HttpKernel\Kernel->handle(object(Request))
(public/index.php:35)
If I register blablabla: { type: 'StripePlatform!' } somewhere, for example the viewer, it works.
Somehow, the validator is super strict. It does not understand that I only refer to the interfaces, and never actual link fields to actual implementations.
Is this a bug, or am I just doing something wrong?
This is not a bug since 0.11 you must explicitly declare object types that can't be auto discover by the schema. See the change here
Aha! Then the interface / inheritance docs are not updated yet. I will make a PR.
Thanks.
Hello, I may be a bit late to the party but I'm failing to understand: how come they cannot be resolved during the static analysis? In the following example:
Query:
type: object
config:
fields:
foo: {type: FooInterface!}
FooInterface:
type: interface
config:
fields:
id: {type: ID!}
resolveType: '@=resolver("foo", [value])'
Bar:
type: object
config:
fields:
id: {type: ID!}
# ...
interfaces: [FooInterface]
Baz:
type: object
config:
fields:
id: {type: ID!}
# ...
interfaces: [FooInterface]
I get that '@=resolver("foo", [value])' is dynamic, nonetheless each implementation declares interfaces: [FooInterface], can't it be inferred from that?
Nevermind I got my answer: during the static analysis graphql-php is looking at the type tree from the root to the leaves. As a result it's possible that some types implementing interfaces never appears in that tree at all, hence the need of an extra step for the user to refer them.
I would however point out that this is very error prone without any further check of the definition files as indeed it means you can easily have definition files that are not scanned - which should be an error: they are either here by mistake or they are not properly configured
I agree with the error prone @theofidry but today we use this to load types between multiple schema without having to separate them in mapping. This is a behavior that going to change and we'll can give some more feedback to dev about unused config files.