Pass descriptive error message when "attachValidation: true" is used

[123NeNaD]

Prerequisites

• I have written a descriptive issue title
• I have searched existing issues to ensure the feature has not already been requested

🚀 Feature Proposal

Looks like Fastify already has a great utility that will create descriptive error messages based on the raw "ajv" result.

However, when attachValidation: true option is used, only the raw "ajv" result will be passed to the request.validationError. Even though this raw result has all the data about the error, constructing a descriptive message requires additional development effort since there are a bunch of use cases to be covered.

I am proposing that when attachValidation: true option is used, we send back a Fastify-generated error as well, as an additional property to the request.validationError.

Or even better, just add a new config that will pass only the Fastify-generated error.

Motivation

The motivation for this feature is to keep maximum flexibility for custom error handling while making it easy to have descriptive error messages out of the box.

Example

Let's take Login functionality as an example.

I would like to have consistent error handling for the whole API, where each error will have a unique error code.

Only in case of input validation, I would like to send back additional context of what failed.

So, if any of the input validation failed, I would send back something like this:

{
  status: false,
  error_code: "LOGIN_ERROR_1",
  message: "body mush have required property 'email'"
}

If the user with the requested email is not found, I would send back something like this:

{
  status: false,
  error_code: "LOGIN_ERROR_2"
}

If a password is not correct, I would send back something like this:

{
  status: false,
  error_code: "LOGIN_ERROR_3"
}

[mcollina]

How are the LOGIN_ERROR_1 LOGIN_ERROR_2 etc generated?

[123NeNaD]

@mcollina They are hardcoded in the specific error response, or extracted from the enum. Something like this:

if (request.validationError?.validation[0]) {
  return { status: false, error_code: 'LOGIN_ERROR_1', error_message: 'Descriptive error message. ' };
}

if(userDoesNotExist) {
  return { status: false, error_code: 'LOGIN_ERROR_2' };
}

if(passwordInvalid){
  return { status: false, error_code: 'LOGIN_ERROR_3' };
}

[mcollina]

I don't really understand what you are asking, but I'd love to see how you would implement this feature. Would you like to send a PR?

[123NeNaD]

@mcollina Sorry if I didn't explain it properly. 😅

Basically, with the attachValidation: false (default), Fastify generates descriptive validation error message like this:

"message": "body must have required property 'obj1'"

But, with the attachValidation: true, the ajv's raw result is passed in the request object:

{
        "statusCode": 400,
        "code": "FST_ERR_VALIDATION",
        "validation": [
            {
                "instancePath": "",
                "schemaPath": "#/required",
                "keyword": "required",
                "params": {
                    "missingProperty": "obj1"
                },
                "message": "must have required property 'obj1'"
            }
        ],
        "validationContext": "body"
}

---

It's hard to construct the descriptive error message based on the ajv's raw result, because there can be multiple types of validation errors.

So, I am suggesting that even with the attachValidation: true, we pass the Fastify's descriptive validation error message together with the ajv's raw result.

[mcollina]

How? I'm not sure it's possible, given how things are set up. Also, generating that message is not really hard, take a look at our implementation.

[climba03003]

It's hard to construct the descriptive error message based on the ajv's raw result, because there can be multiple types of validation errors.

I don't see why it would be hard to implement. The message is generated by ajv, you can see it inside the validation property.
fastify just concat it all together with validationContext, nothing special is done.