Open bhrigushr opened 1 year ago
I was able to catch this error in v5.1.0
.
My code looked like
async readmeInterceptor(req, res, data: ReadmeData): Promise<void> {
readme
.log(
README_CONFIG.apiKey,
req,
res,
{
apiKey: data.apiKey,
label: data.label,
email: data.email,
startedDateTime: data.startedDateTime,
responseEndDateTime: data.responseEndDateTime,
},
{
fireAndForget: false,
// optional, enable in development mode
development: !IS_PROD,
// denyList: [], // array of any sensitive fields returned by API
},
)
.then((result) => {
this.logger.debug(result, { teamId: data.teamId });
})
.catch((error) => {
this.logger.error(error, { teamId: data.teamId });
});
return Promise.resolve();
}
But in v6.1.0
readme.log
is no longer thenable so unable to use above code
Hey! Thanks for sending this over. What looks to be happening is the timeout that we have set could be getting hit (https://github.com/readmeio/metrics-sdks/blob/0c5e0c19e96018cca79de968204febdc06fc213c/packages/node/src/lib/metrics-log.ts#L93C42-L93C42) and that's causing the http request that goes out to our metrics backend to get aborted and fail. Are you able to share a little more information about the environment in which this code is running? Could there be a firewall or a proxy or something that's blocking/slowing down the outbound request? What is the contents of your API request/response pair - is it a particularly large request body that could be taking that long to upload to us?
Yeah the timeout is internal and not exposed currently. I suspect the issue then may be to do with those large payloads, and it's possible they were failing before but the errors weren't surfaced anywhere. Is there a pattern for when the payloads are large e.g. a specific endpoint? If so, you could try and bypass the middleware for those endpoints:
async readmeInterceptor(req, res, data: ReadmeData): Promise<void> {
if (req.url === '/api/large-payloads-here') return;
readme.log()
}
Or do the payloads have a specific name to omit them from the payload altogether using the denyList?
readme.log(
README_CONFIG.apiKey,
req,
res,
{
//
},
{
// options here
denyList: ['some-big-payload-key'], // array of any sensitive fields returned by API
},
)
We can potentially expose the timeout option if neither of these work or are sufficient?
@domharrington it would be better if have timeout
option exposed as even after incorporating the above-mentioned changes there are still cases where we are still getting errors.
Same here when readme.io
tries to intercept response of HTTP PUT
request with formData
payload type. I'm using NestJS.
request options
{
protocol: "https:",
slashes: true,
auth: null,
host: "metrics.readme.io",
port: null,
hostname: "metrics.readme.io",
hash: null,
search: null,
query: null,
pathname: "/v1/request",
path: "/v1/request",
href: "https://metrics.readme.io/v1/request",
method: "POST",
headers: {
Authorization: [
"Basic XXXXXXXXXX==",
],
"Content-Type": [
"application/json",
],
"User-Agent": [
"readmeio/6.2.0",
],
Accept: [
"*/*",
],
"Content-Length": [
"1217721",
],
"Accept-Encoding": [
"gzip,deflate",
],
Connection: [
"close",
],
},
agent: undefined,
}
request params
{
size: 0,
timeout: 0,
follow: 20,
compress: true,
counter: 0,
agent: undefined,
}
All that was caught in node-fetch
package, whose methods was fired by metricsAPICall()
⬆️ doSend()
⬆️ startSend()
methods in readmeio
package.
After upgrading NodeJs SDK(readmeio) from
5.1.0
to6.1.0
I am seeing too many Abort errors & unable to catch them which causes the server to crash.Error ->
My Code looks like this
Let me know how to handle this AbortError