got: Throw helpful error messages
What problem are you trying to solve?
I’m using Github API. On error (non-200 http status) got
throws an HTTPError which is by default printed like this:
HTTPError: Response code 422 (Unprocessable Entity)
at EventEmitter.<anonymous> (.../node_modules/got/dist/source/as-promise.js:118:31)
at processTicksAndRejections (internal/process/task_queues.js:97:5) {
name: 'HTTPError'
}
It gives me no information from the response body to be able to debug the issue (e.g on the local machine, or from the server logs in production).
Describe the feature
What I’d like to see is that it’d print the response.body
, e.g by including it in Error.message (maybe limiting the maximum length, for sanity). Now I need to add this code to achieve the needed result:
await got(...)
.catch(err => {
console.log((err as HTTPError).response.body)
})
Then it prints like this:
{"message":"Reference already exists","documentation_url":"https://developer.github.com/v3/git/refs/#create-a-reference"}
And suddenly the error message becomes very useful.
I’m aware that I can use Hooks, extend my got
instance with some error-handling hook to achieve that (that what I’m going to try now). But wouldn’t everyone benefit from such feature enabled by default in got
? Or behind a non-default configuration flag?
…
Checklist
- I have read the documentation and made sure this feature doesn’t already exist.
About this issue
- Original URL
- State: open
- Created 4 years ago
- Reactions: 29
- Comments: 24 (2 by maintainers)
got.HTTPError
has a lot of useful properties withinrequest
andresponse
, but they are non-enumerable for some reason. This means that they don’t get printed byconsole.error()
(which usesutil.inspect()
under the hood). The only property that is enumerable istimings
, which is probably the least useful property out of all of them. This makes the log output of Got errors very verbose, with providing almost no useful information in that output (very bad signal/noise ratio):Agreed
TL;DR The default behavior of got library should balance security and pragmatism and should be configurable by the user
@szmarczak @sindresorhus I’m very happy to hear that error.options will become enumerable out of the box in got@12. I reported this a very long time ago here https://github.com/sindresorhus/got/issues/1067 I’m curious what changed in the meantime.
I’m afraid that making whole error.options enumerable it’s going to be too verbose unless irrelevant/null/undefined properties are filtered out but it’s definitely better than nothing.
Regarding error.body in most cases servers responding with 4xx or 5xx do not include sensitive data but information about why the error occurred. For example Google Storage API returns information about missing permissions which is very helpful for debugging (service account myapp does not have permission storage.objects.write for bucket mybucket).
On one side there is a security concern if
On the other side debugging every HTTP issue is taking minutes or hours instead of seconds OR you end up with a lot of boilerplate code OR you have to use a beforeError hook. None of those is preferable.
I propose that at the very least a set of properties considered safe are enumerable by default:
Currently I end up with code like this because got errors are useless in an application that calls multiple endpoints. I can’t even know which API call failed unless I use a beforeError hook or this:
I would like to see a sane default behavior in a future release of got. I would prefer having sensitive information in logs over writing code like this or spending time trying to reproduce or guess an error to see which API call failed every time it happens.
In Got v12,
error.options
is enumerable so it looks like this:click here
We could attach
error.body
but trimmed down to 100 characters.@sindresorhus Any thoughts?
I agree too. I’m starting to use the lib and that was my first unconfortable usecase. Would be awesome to receive formated erros by default.
I made this to change Got Error and get response error (I use got-cjs, not directly got) :
For the record, I (the topic starter) “solved” it for myself by wrapping
got
with some function that addsbeforeError
hook by default (and alters some other defaults, unrelated to this issue), and it lives here: https://github.com/NaturalCycles/nodejs-lib/blob/master/src/got/getGot.ts#L68@aalexgabi, your last message very well described the experience that I had when opening this issue.
No one has commented whether it’s safe to expose the body on the error though. I’m not against doing it, but I am concerned it will later turn into a security vulnerability of some kind. Someone will have to do some research about it.
One way to figure this out would be to look at other popular request libraries. For example, the Python one doesn’t seem to expose the body directly on the error: https://stackoverflow.com/a/58085336/64949
There are multiple ways we could solve this:
process.env.NODE_ENV === 'DEBUG'
.The problem is we can’t identify what kind of actual errors are really sent from the API, for example, 400 Bad Request could mean an invalid token but it could be mean something else too.