DateTime/Enum types doesn't show invalid input data

[MGDSoft]

Hi,

If I have a param with DateTime and write a bad input, It doesnt show an error. And in resolver I get a null value...

Example

class PepField extends AbstractFieldMutation
{
    public function buildParent(FieldConfig $config)
    {
        $config
            ->setDescription('Deactivates a user')
            ->addArguments([
                'date'  => new DateTimeTzType(),
            ])
        ;
    }

    public function resolve($value, $args, ResolveInfo $info)
    {

        return true;
    }

    /**
     * @return AbstractObjectType|AbstractType
     */
    public function getType()
    {
        return new BooleanType();
    }
}

Execute with this query

mutation{
  pep(date: "asdasd")
}

and result is

{
  "data": {
    "pep": true
  }
}

Looking for this "error" I found the class ResolveValidator, lines 54 - 60

if (!$argument->getType()->isValidValue($argumentType->parseValue($astArgument->getValue()))) {
     $error = $argument->getType()->getLastError();
     throw new ResolveException($error ? $error : sprintf('Not valid type for argument "%s" in query "%s"', $astArgument->getName(), $field->getName()), $astArgument->getLocation());
 }

The problem here is the function parseValue return a null value and isValidValue verify input NULL instead of original value.

SOLUTION
I think inside the function "isValidValue" (AbstractType) should be call inside to "parseValue", to know the original value and if It get a NULL it will throw an error.

if (!$argument->getType()->isValidValue($astArgument->getValue())) {
    $error = $argument->getType()->getLastError();
    throw new ResolveException($error ? $error : sprintf('Not valid type for argument "%s" in query "%s"', $astArgument->getName(), $field->getName()), $astArgument->getLocation());
}

and each Validator call to parseValue if it's necessary

I can create a pull request if you give me the approval

[dilab]

I have encountered the same issue, with a ENUM type.
I agree with you. The validation should happen on the original value, instead of setting it to NULL , and then validate.

[dilab]

@MGDSoft Are you pushing any PR?

[MGDSoft]

@dilab I have had bad experience doing PR that were not accepted. Until I get the okay I will not do it :/

[dilab]

@MGDSoft sorry to hear about that.

@viniychuk would you accept this PR?

[viniychuk]

@dilab I absolutely will, let's just check the core idea here, will reply later tonight.. @MGDSoft sorry about your bad experience. I'll write contribution guidelines to improve this in the future

[fritz-gerneth]

I just learned the hard way this was actually a BC break. Any custom Scalar type now has to call parseValue on their own when receiving a raw value. Previously isValidValue could rely on the value always already being parsed (or being null).

[miclud]

I just had the same experience as @fritz-gerneth.

[arthens]

Just ran into it too. Still not sure what the right solution is (define custom and more permissive types for int/float/etc.?)