-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
failAction: detailedError to log, defaultError to response #4229
Comments
import Joi from 'joi'; // 17.4.0
server.route({
method: 'GET',
path: '/test',
options: {
validate: {
query: Joi.object({
foo: Joi.string().required(),
}),
failAction: 'error',
// response: {"statusCode":400,"error":"Bad Request","message":"Invalid request query input"}
failAction: 'log',
// log to console: Error: Invalid request query input
failAction(request, h, err) {
request.log('error', err);
throw err;
},
// log to console: Error [ValidationError]: "foo" is not allowed to be empty
// response: {"statusCode":400,"error":"Bad Request","message":"\"foo\" is not allowed to be empty","validation":{"source":"query","keys":["foo"]}}
},
},
handler() {
return 'ok';
},
}); There is no way to response by short error |
Yeah, I always use the last one and I do it at the server level: failAction(request, h, err) {
request.log('error', err);
throw err;
}, The other modes seem pretty pointless to me. I think you'd always want the detailed error in the logs and the only thing that really needs configuration is whether to return the detailed error in the response. |
I believe this is a valid feature request. Even though you could throw a We could handle this in a non-breaking way by adding If we go that route and don't want to publish a breaking change, I'd suggest we also keep an issue open for the next major version release to replace it with: In the end the failAction(request, h, detailedError | defaultError, defaultError) {} |
That's a good thought. Another approach could be to tack the default error onto the detailed error in this case so that it could be accessed: failAction(request, h, err) {
request.log('error', err);
throw err.defaultError;
} |
Another somewhat related problem is how the default error message includes "request query input", which is useful to know, but the detailed error message doesn't include that source info. So in my logs, for example, I have to choose between:
Except, option 1 isn't really an option for me, because It's also kind of odd how option 1 includes a (relatively useless) stack trace while option 2 does not. Personally, all of this stuff is my biggest pain point with hapi right now. |
Good idea @devinivy . I didn't think of this one. Would you consider it a transitional step before a breaking change or the final implementation? Thanks @sholladay . Interesting stuff to consider as well. |
I'm really happy that this feature has found followers. I'm looking forward to have it implemented in any from proposed option. |
This is exactly what I was looking for. I implemented this behavior but it was a bit hacky without having the This implementation is TS and typesafe. That is the reason for some (maybe unnecessary) checks: import {ValidationError} from "joi";
failAction: (request, _h, err): null => {
if (Boom.isBoom(err)) {
const validation = err.output.payload.validation as
| { source?: string }
| undefined;
const source = validation?.source ?? '';
if (err instanceof ValidationError) {
request.log(['validation', 'error', source], err.message);
}
throw Boom.badRequest(`Invalid request ${source} input`);
} else {
// should never be the case, because a failAction is always called with a Boom error
throw Boom.badRequest('Invalid request input');
}
} So in short maybe: failAction: (request, h, err) => {
const source = err.output.payload.validation?.source
request.log(['validation', 'error', source], err.message);
throw Boom.badRequest(`Invalid request ${source} input`);
} |
Resolved with v21 #4386 |
Support plan
Context
What problem are you trying to solve?
It is impossible to log
detailedError
to the console,defaultError
to the response.Current implementation allows:
There is no way to access both
detailedError
anddefaultError
in the handler.For example:
Do you have a new or modified API suggestion to solve the problem?
https://github.com/hapijs/hapi/blob/master/lib/toolkit.js#L117-L135
The text was updated successfully, but these errors were encountered: