-
Notifications
You must be signed in to change notification settings - Fork 25
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
Nodejs Abort error #876
Comments
I was able to catch this error in 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 |
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 |
Same here when 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,
} Request body is UInt8Array with length like 1217721Short version here:
All that was caught in |
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
The text was updated successfully, but these errors were encountered: