While reporting error to Laravel's ExceptionHandler::handle, doesn't satisfy the Exception type

[ssi-anik]

Laravel Version: 6.18.25
Lighthouse version: ^4.15
PHP version: 7.4.7

Laravel configuration: Default configuration
Lighthouse configuration: Default configuration

I created my own mutation resolver, and I used the arguments to my function like $rootValue, array $args, GraphQLContext $context = null, ResolveInfo $resolveInfo. I forgot to import the ResolveInfo class. Thus, the compiler thought the class resides in App\GraphQL\Mutations namespace. Which it doesn't.

So, when I executed the mutation, it showed the error like below.

I ran dd(get_class($error), class_implements($error), get_class($error->getPrevious()), class_implements($error->getPrevious())); in Nuwave\Lighthouse\Execution\ReportingErrorHandler::20 and found

So, I changed $error->getPrevious() to $error in Nuwave\Lighthouse\Execution\ReportingErrorHandler::25 and found the following which I think should be the actual behavior.

---

• In my server,

type Mutation {
    jwtLogin(input: LoginInput @spread): AuthPayload! @field(resolver: "AuthMutation@jwtLogin")
}

• In my mutation

<?php

namespace App\GraphQL\Mutations;

use Nuwave\Lighthouse\Support\Contracts\GraphQLContext;

class AuthMutation 
{
    public function jwtLogin ($rootValue, array $args, GraphQLContext $context = null, ResolveInfo $resolveInfo) {
        // login goes here
    }
}

• In my client

mutation {
  jwtLogin(input: {
    username:"admin@example.com"
    password: "12345"
  }) {
    access_token
    refresh_token
    expires_in
    token_type
    user{
      id
      name
      email
    }
  }
}

[spawnia]

Thanks for the detailed report and really digging into this.

The real issue is Laravel's ExceptionHandler, which is not equipped to deal with subclasses of Error. In this case, the underlying TypeError is produced by PHP itself.

I recommend to upgrade to Laravel 7, where they fixed their error handler.

[spawnia]

Oh and another tip how you can save boilerplate when declaring your mutation:

type Mutation {
    jwtLogin(input: LoginInput @spread): AuthPayload!
}

<?php declare(strict_types=1);

namespace App\GraphQL\Mutations;

class JwtLogin
{
    public function __invoke($_, array $args)
    {
        // login goes here
    }
}

[ssi-anik]

@spawnia, thanks man for the suggestion. I was actually trying to get my hand dirty. Want to know how things are done and work. And the purpose behind that was to reuse the same class as we do in controllers.

Thanks anyway. <3

[spawnia]

Resolver classes - just like controllers - are only meant to be glue code. Reusable logic should go somewhere else.

[ssi-anik]

One more point I'd like to share, as Laravel internally handles the \Throwable type and processes according to it, why don't you follow it? Because you can't just stop people from using L6 and to switch to L7.
I had thrown a \TypeError and Laravel internally managed it.

Just a suggestion.

---

---

[spawnia]

There is more important work to do. Basic static analysis will prevent TypeError from occuring, so I don't see much need to safeguard this at runtime.

GraphQL is all about static validation, so that philosophy extends to its usage.