InvalidInputException returns wrong status code

[sasokovacic]

Hi, InvalidInputException should return status code 422 and not 500.
5XX are server errors and 4XX are client errors. I get this status when I validate user input...
As I can see there is no way to set status code on your Validator class

[Kenny Horna]

Could you provide the related code and steps to reproduce?

[sasokovacic]

`namespace App\Domains\User;

use Lucid\Foundation\Validator;

class NewUserValidator extends Validator
{
protected $rules = [
'last_name' => 'required',
'first_name' => 'required',
'email' => 'required|email|unique:users,email',
'is_enabled' => 'required|boolean',
'password' => 'required|min:6|password',
'password_confirmation' => 'required|same:password'
];

public function validateInput($input, array $rules = [], array $messages = [])
{
    return parent::validate($input, $rules);
}

}
`

[sasokovacic]

Anything new about this issue? I think this is a fundamental and very important aspect of the app and it should be fixed... Right now I'm using my own implementation but it would be really nice to use yours

[Harris Raftopoulos]

Hello @sasokovacic ,

I haven’t had the time to check this issue yet, I apologize. I will take a look once I get some free time.
In the meantime, we would really appreciate a PR from your side, since you already have a working implementation - fix.

[Abed Halawi]

@sasokovacic still care to elaborate on the issue? i don't really get where exactly the issue is? is it the response? or the default error code? because it should be 400 rather than 500.

[sasokovacic]

Sorry, I didn't have time to create a PR. If I understand correctly, the purpose of the Lucid\Foundation\Validator class is to validate user input. But this class throws error code 500 instead of 4**. 500 is reserved for server errors, not for user validation. I'm catching error codes on the frontend and showing error messages. For error code 500 I show a general error message and for 4** error codes I show an error message for specific invalid input.

[Abed Halawi]

I totally agree that the response should never be 500 for a validation error. But the validator isn't responsible for the response that is being returned. The validator's job is to throw the exception, then in app/Exceptions/Handler.php you would add the handling logic:

use Lucid\Foundation\MarshalTrait;
use Lucid\Foundation\JobDispatcherTrait;
use Illuminate\Foundation\Bus\DispatchesJobs;

class Handler extends ExceptionHandler
{
    use MarshalTrait;
    use DispatchesJobs;
    use JobDispatcherTrait;

    public function render($request, Throwable $exception)
    {
         if ($exception instanceof InvalidInputException) {

            return $this->run(RespondWithJsonErrorJob::class, [
                'code' => 400,
                'message' => $exception->getMessage(),
            ]);
        }
    }
}

This is not shipped by default with LUCID because we can't know what you would like to respond with (JSON or a view or whichever the case of your application is).

Do you see that it would be beneficial for such code to be shipped along the initial implementation?

[Nico R. Penaredondo]

Hi @Mulkave,

tried your example code snippet and I encountered this error.

Error: Call to undefined method Framework\Exceptions\Handler::marshal()

[Abed Halawi]

@nicopenaredondo indeed, that snippet was missing a few more traits. I think it's about time Lucid introduced a handler which this Handler extends. On the list! Updated my comment and added the missing traits please check again, and sorry about this.

[Nico R. Penaredondo]

Thanks @Mulkave

[sasokovacic]

Hi @Mulkave, thanks for your explanation. I agree it's a better approach to let the developer decide what he/she wants. But this approach is a little bit different than Laravel's. Laravel's validator automagically handles these responses. It automatically redirects the user or in the case of ajax call it returns a JSON response with status code 422. I expected the same behavior with your validator. That's why I wrote this issue.

It's not necessary to put this into the initial implementation but it would be practical to have it available. You could also just mention this in some kind of a "best practice" guide with some other tips & tricks so we can learn to make better implementations. I created my own but I prefer yours more.

Thanks again for your help

[Abed Halawi]

@sasokovacic thank you for raising the flag on this, it indeed shows a missing piece of the Lucid puzzle. I will take that into consideration for the next iteration of updates!

Glad to be of help