HttpErrors.InternalServerError does not report my custom message

[sertal70]

Hi all,
I'm facing an issue using HttpErrors. In any controller, if I throw any HttpErrors.* I can pass a custom message and this is then included in the JSON returned to client. For instance, if I do:

throw new HttpErrors.Unauthorized('email format not valid');

then the client receive the following JSON (note the name and message fields):

{
    "error": {
        "statusCode": 401,
        "name": "UnauthorizedError",
        "message": "email format not valid"
    }
}

But if I throw an Internal Server Error like this:

throw new HttpErrors.InternalServerError('my custom message');

the JSON returned to the client is:

{
    "error": {
        "statusCode": 500,
        "message": "Internal Server Error"
    }
}

as you can see, the name field is not reported and its content is in the message field , which should instead contain my custom message.

Steps to reproduce

In any controller of a lb4 application throw the InternalServerError Error using a custom message:

throw new HttpErrors.InternalServerError('my custom message');

Current Behavior

The following JSON is returned to the client:

{
    "error": {
        "statusCode": 500,
        "message": "Internal Server Error"
    }
}

Expected Behavior

I would expect to receive a JSON similar to the one returned for others HTTP Errors, having the following format:

{
    "error": {
        "statusCode": 500,
        "name": "Internal Server Error",
        "message": "my custom message"
    }
}

Additional information

$node -e 'console.log(process.platform, process.arch, process.versions.node)'
darwin x64 8.9.3
$npm ls --prod --depth 0 | grep loopback
├── @loopback/[email protected]
├── @loopback/[email protected]
├── @loopback/[email protected]
├── @loopback/[email protected]
├── @loopback/[email protected]
├── @loopback/[email protected]
├── @loopback/[email protected]
├── @loopback/[email protected]
├── @loopback/[email protected]
├── [email protected]

[dougal83]

You might find that you are running into strong error handling behaviour so I don't think that it is a bug but by design. 5xx errors are obscured and only deliver details to the end user in debug mode. Maybe catch internal server errors and rethrow(as non-5xx) as you see fit? Not sure that is the best idea though... be careful.

https://loopback.io/doc/en/lb3/Using-strong-error-handler.html

[sertal70]

thanks @dougal83 for your thought. The strong-error-handler package is for lb3 and I can't find anything similar in lb4, also it is not mentioned in the feature parity page. Anyway, maybe the behaviour is by design but:

• why for 500 errors the code name is reported in the json field message instead of name (as it is done for other errors)? It seems a bug to me...
• why the business logic code cannot emit a 500 error? It can be useful in many production scenarios: suppose the backend has a database error (connection or wathever), in cases like that it make sense to return a 500 error to the client with additional informations (something like "I can't access database, please don't retry')

I'd like to know what is the opinion of loopback team members on this...

[dougal83]

To be helpful I googled it for you:
#1867 (comment)

[bajtos]

Thank you @dougal83 for helping out, you are right - LB4 is using strong-error-handler under the hood.

The details are described in our documentation here: https://loopback.io/doc/en/lb4/Sequence.html#handling-errors

@sertal70 you can enable debug mode if you want to see details for 500 errors too (see the docs). Just be aware that your application may leak sensitive data this way. For example, when the app cannot connect to backend service/database, the host+port information about your service will be often included in error details.

[dhmlau]

Closing due to inactivity.