[SEMVER-MAJOR] Remove loopback#errorHandler middleware

[loay]

connect to #2338

[bajtos]

@loay Could you please link this pull request with the GH issue where we discussed this change? I think it will be better to completely remove loopback#errorHandler middleware, what are the arguments for keeping it around?

[bajtos]

@loay please add an entry into 3.0-RELEASE-NOTES.md, don't forget to include a link to this pull request - see other entries for inspiration.

[loay]

@slnode test please

[loay]

In test/relations.integration.js, this line was failing the tests :

expect(res.body.error.statusCode).to.equal(500); ,

as it was set to undefined so I changed it to

expect(res.body.error.status).to.equal(500); ,

and it did run fine locally, as res.body.error.status was giving the expected value of 500. However it is still failing the ci testings for the same reason of being undefined. I commented out the line and it finally passed.

@bajtos PTAL

[bajtos]

Remove loopback#errorhandler

We have removed loopback#errorhandler middleware, users should use strong-error-handler directly.

// server/middleware.json{// ..."final:after": {"strong-error-handler": {}}}// server/middleware.development.json{"final:after": {"strong-error-handler": {"params": {"debug": true}}}

See also strong-error-handler's options and the related code change.

[bajtos]

^^^ click on the "edit" icon of the comment above, copy the markdown source and use it to replace the content of the new section you are adding.

[bajtos]

@loay reviewed, PTAL

[loay]

@bajtos PTAL. Thanks

[bajtos]

Could you please check with @davidcheung whether this change is needed. I am surprised that body.error.statusCode is not available.

[bajtos]

The code change LGTM, please make sure Travis CI builds and Jenkins builds (possibly excluding unstable dependants) are passing before landing.

[bajtos]

@loay also squash the commits before landing :)

[bajtos]

We don't put space between function name and argument list, i.e. Error(

Could you please add a rule to our eslint config to catch this?

[rickyngk]

I'n using strongErrorHandler with loopback 3.0.0-alpha.1. That's really a pain. It annoyed me with sort of message e.g: "Unhandled error for request GET /MyModel/action". How can I turn it off? I also disabled log & debug in both middleware.json and middleware.development.json, but no help

"final:after": {
"strong-error-handler": {
"params": {
"debug": true,
"log": true
}
}
}

Btw, I use loggy to store error message. For loopback 2.x, I send error log in config.local.js

module.exports={restApiRoot: '/api'+(version>0 ? '/v'+version : ''),host: process.env.HOST||'localhost',port: process.env.PORT||3000,remoting: {errorHandler: {handler: function(err,req,res,next){log.l('api-error',{method: req.method,originalUrl: req.originalUrl,statusCode: res.statusCode,stack: err.stack,});next(err);},},},};

But err.stack is not available in 3.x. I have to change it to req.remotingContext.error

How can I do this officially?

[ttothAISS]

Hi @rickyngk !

I have encountered the same issue.

The problem is the RestAdapter.errorHandler in the rest-adapter.js calling the new strongErrorHandler with ITS OWN option object, not the one the documentation suggest in the server/middleware.json.

To overcome and apply your desired params use the following in the server/config.json:

"remoting": {
...
"errorHandler": {
"debug": false,
"log": false
...
}

@bajtos this should be mentioned in the migrate doc, because the full migration is not possible right now if you want to use options when using the strong error handler for the REST adapter.

T.

[davidcheung]

@ttothAISS thanks for pointing it out, the migration guide for REST adapter error-handler should be this instead, will follow up and fix