Closed adityapatadia closed 4 years ago
This has been also fixed in #1051
You need to access the response via error.response
, the docs are outdated
Is this going to be consistent in future versions? Or is it going to change in #1051 ?
I don't know exactly what do you mean, but this issue is fixed in #1051.
I meant currently err.response
works. My question is will the function be .on("error", (err, body, response)= {})
or it will be .on("error", (err)= {})
? Are you going to update the docs with the existing functionality or you are going to give functionality as per current docs?
I am asking because if it's going to change, we will also need to change code.
.on('error', error => { ... })
Cool. I will disregard the docs then. I am doing coding as per err.response
now.
Btw, I found another bug. Even if decompress:true
is passed, the error.response.body
is not decompressed if it's a gzip
from the server. Should I report that one?
yes, it'd be best to include some reproducible code (but I think I can sketch something on my own so that's not necessary, but it will be welcome)
Opened #1142
Describe the bug
Actual behavior
When
isStream: true
is set and request results in HTTPError, the stream emitserror
event. The emit handler is only called witherror
argument andbody
andresponse
arguments areundefined
....
Expected behavior
As per the docs, the
body
andresponse
arguments should be set witherror
event. ...Code to reproduce
Checklist