Graphqlbundle: Multiple schemas defined, TypeResolver not set to the right schema name

Created on 14 Aug 2019 · 3Comments · Source: overblog/GraphQLBundle

| Q | A
| ---------------- | -----
| Bug report? | yes
| Feature request? | no
| BC Break report? | no
| RFC? | no
| Version/Branch | 0.12

If you define multiple schemas, for instance like this ...

overblog_graphql:
    definitions:
        schema:
            one:
                query: Query
                resolver_maps:
                    - App\GraphQL\Resolver\OneResolverMap
            two:
                query: TwoQuery

... it seems that when lazily resolving types, the resolver is currently always called with the name of the second schema. It seems this stems from multiple calls to TypeResolver->setCurrentSchemaName(), the last one being from the definition of the TwoQuery type in the two schema.

However, when the resolver then tries to resolve a type from the one schema, it accidentally thinks it is still resolving within the two schema.

I've already come up with two solutions that both work:

1: Add a line in the endpointAction in the GraphController so that the right schema is forced within the TypeResolver (& inject the resolver in the controller service of course):

    /**
     * @param Request     $request
     * @param string|null $schemaName
     *
     * @return JsonResponse|Response
     */
    public function endpointAction(Request $request, string $schemaName = null)
    {
        $this->typeResolver->setCurrentSchemaName($schemaName);
        return $this->createResponse($request, $schemaName, false);
    }

This feels hackish.

So 2: Fix the generated classes. The issue is that the call to$globalVariable->get('typeResolver')->resolve() is dependent on whether the TypeResolver has been primed with the right schema name first. The best fix would be to make sure that the generated class _knows_ which schema it is in, and set the TypeResolver with the right schema name before invoking the resolve method. For instance:

// ...

final class AccountClassificationNameType extends ObjectType implements GeneratedTypeInterface
{
    const NAME = 'AccountClassificationName';

    public function __construct(ConfigProcessor $configProcessor, GlobalVariables $globalVariables = null)
    {
        $configLoader = function(GlobalVariables $globalVariable) {
            return [
            'name' => 'AccountClassificationName',
            'description' => 'Crm AccountClassificationNames',
            'fields' => function () use ($globalVariable) {
                // vvv Insert this line vvv
                $globalVariable->get('typeResolver')->setCurrentSchemaName('one');
                // ^^^ Insert this line ^^^
                return [
                'Created' => [
                    'type' => $globalVariable->get('typeResolver')->resolve('DateTime'),

// ...

What do you think about this issue? Am I missing something that would prevent this issue? Is there perhaps a better fix? If this fix is good, how to implement it? Since the generator and the classes it is generating currently have no knowledge of the schema name, it would involve changing quite a lot of code, which I'm happy to do if you think this is a good approach.

Source