Partial Error That Doesn't Nullify Data

[ievgenklymenko]

Is there a natural solution for partial errors?

Say we have an existing schema, with a scalar non-nullable field, and we need both the field data and error which occurred when resolving that field presented in top-level 'errors' in response; this is legal by GraphQL spec.

#374 issue was closed, but solved only for that, particular, (array data) case. Because there, it is possible to return exception (which turns to null in response) instead of array element. But we can't return exception because that would erase resolved data.

So the only solution is to do manual manipulations with response, is that it? There is no natural way of doing it in webonyx/graphql-php ?

[vladar]

It should be really straightforward to do in the userland by utilizing context. Something along the lines:

Resolver:

use GraphQL\Error\Error;

'resolve' => function($parentValue, $args, $context, $info) {
    $context->errors[] = Error::createLocatedError('Error message', $info->fieldNodes, $info->path);
    return '';
}

Then when you run the query:

$context = new MyContext();
$result = GraphQL::executeQuery($schema, $source, null, $context);
$result->errors = array_merge($result->errors, $context->errors);

[spawnia]

@vladar we recently implemented something quite similar to your suggested approach in Lighthouse. Works good so far.

I wonder if we could ease support by adding a special result class that graphql-php recognizes:

class Result {
    /** @var mixed The value returned from the resolver */
    public $value;

    /** @var array<\Throwable> Non-fatal errors that come up during resolution */
    public $errors = [];
}

We could then check in the executor:

$result = $resolver(...);

if ($result instanceof Result) {
  $this->addErrorsToContext($result->errors);
  $result = $result->value;
}

[vladar]

Yeah, I had a similar idea in the past with a potentially wider scope: #225 But never saw a real-world demand for it or a benefit that would justify adding this complexity.

And actually I think the better approach would be to suggest this kind of thing in graphql-js first and then port it here.