Bug when parsing dynamic query string

[dilab]

Test Field

namespace App\Graphql\Schema\Field;


use Youshido\GraphQL\Config\Field\FieldConfig;
use Youshido\GraphQL\Execution\ResolveInfo;
use Youshido\GraphQL\Field\AbstractField;
use Youshido\GraphQL\Type\Scalar\IntType;
use Youshido\GraphQL\Type\Scalar\StringType;

class TestField extends AbstractField
{
    public function getType()
    {
        return new StringType();
    }

    public function resolve($value, array $args, ResolveInfo $info)
    {
       return var_export($args, true);
    }

    public function build(FieldConfig $config)
    {
        $config->addArgument('id', new IntType());
    }
}

Query with dynamic variables

Query string

query Test($id: Int) {
  test(id: $id)
}

Query variable

{}

Result

{
  "data": {
    "test": "array (\n  'id' => NULL,\n)"
  }
}

Bug

IMO, in this case, "id" should not be set because client-side has never sent the "id" variable. By setting a default NULL value cause confusion and lead to bugs.

[dilab]

More reference to back up
Secion 5.e
https://facebook.github.io/graphql/#CoerceArgumentValues()

[dilab]

After digging further, I realised that youshido/graphql will set Boolean input to false as the default value if it is not provided.

<?php

namespace App\Graphql\Schema\Field;


use Youshido\GraphQL\Config\Field\FieldConfig;
use Youshido\GraphQL\Execution\ResolveInfo;
use Youshido\GraphQL\Field\AbstractField;
use Youshido\GraphQL\Type\Scalar\BooleanType;
use Youshido\GraphQL\Type\Scalar\IntType;
use Youshido\GraphQL\Type\Scalar\StringType;

class TestField extends AbstractField
{
    public function getType()
    {
        return new StringType();
    }

    public function resolve($value, array $args, ResolveInfo $info)
    {
        return var_export($args, true);
    }

    public function build(FieldConfig $config)
    {
        $config->addArgument('id', new BooleanType());
    }
}

Output

{
  "data": {
    "test": "array (\n  'id' => false,\n)"
  }
}

This should prove that it is indeed a bug?

[dilab]

@viniychuk is this ticket going anywhere? Would appreciate your input.

[viniychuk]

@dilab I believe it should throw an error because you actually specified a variable on the client side and never sent it.
update After spending some time – I need to get some input back. It's technically a correct query, but all together with variables it's not.
I've made a change that is producing an error with a details about the query.