GraphQL specs violation by throwing UserWarning for access deny and general usage of it described in the bundle docs

[inwaar]

Q	A
Bug report?	yes
Feature request?	no
BC Break report?	no
RFC?	yes
Version/Branch	0.13.5

The documentation https://github.com/overblog/GraphQLBundle/blob/master/docs/error-handling/index.md shows a few examples of throwing exceptions in resolvers:

Using UserError:

if (!isset($humans[$args['human_id']])) {
    $errors[] = new UserError(sprintf('Could not find Human#%d', $args['human_id']));
}

And using UserWarning

if (!isset($humans[$args['id']])) {
    throw new UserWarning(sprintf('Could not find Human#%d', $args['id']));
}

Everything is clear with UserError, but in which cases UserWarning has/can be used?

If I throw the UserWarning exception I get the following response:

And in that case it just goes right into the .subscribe on frontend as a successful execution while it has no data (as expected when you throw any exceptions in a resolver)

return this.apollo.mutate(...).subscribe(response => {
    ...
});

This happens even if the data type of the mutation is not null-able.

It seems that it does not comply to the GraphQL specs: http://spec.graphql.org/June2018/#sec-Errors Specifically: If the data entry in the response is not present, the errors entry in the response must not be empty. It must contain at least one error. The errors it contains should indicate why no data was able to be returned.

[inwaar]

Another case making the bundle not comply with the GraphQL specs: If access is restricted to a root query it raises the UserWarning and there is no data or errors in the response but only extensions.

This makes the apollo client considers such requests as successful.

I see there some kind of probably correct handling this for mutations:

But why only for mutations but not the queries? Could somebody acknowledge this as a bug?

[inwaar]

Is there any update on this? This problems makes it impossible to use this bundle with ApolloClient and access config on the query type since the request always processed as success while they are not.