Error: ESOCKETTIMEDOUT with REST request


#1

We have a few services on our fulfillment system reading and writing to hubspot through the REST api and it has been running fine for months. All of a sudden we are getting plastered with Error: ESOCKETTIMEDOUT when waiting for a response to our requests.

  1. This does not always occur.
  2. The request is being processed, we are just not getting our confirmation back and are timing out.

We are using node.js with the following module:

I have increased the default timeout from 15 seconds to 30 seconds.
I have checked the available sockets on our system and we are not over limit.

Any similar experiences or suggestions?


#2

Hi @RJ_Forbes,

While I’m not particularly familiar with the 3rd party wrapper you’ve listed, ESOCKETTIMEDOUT can often be resolved by increasing your uv thread pool size (see below).


#3

Thank you for the help @Derek_Gervais , this seems to have stopped the errors from occurring now. Next I will have to investigate why this started happening on this instance.

Cheers,
RJ


#5

I spoke too soon, received another timeout this morning. It had run throughout the night without issue, processing a dozen or so API requests, then this morning it timed out waiting for Deal info.


#6

I have a log that may help some more, it seems to be happening when trying to update deals.

Basically just a PUT of json at http://api.hubapi.com/deals/v1/deal/ . Once again the data was written to hubspot but i did not get a confirmation back and timed out.

{"__error_callsites":[{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{}],“stack”:“RequestError: Error: ESOCKETTIMEDOUT\n at new RequestError (/data/node/fulfillment/fulfillmentService/node_modules/request-promise-core/lib/errors.js:14:15)\n at Request.plumbing.callback (/data/node/fulfillment/fulfillmentService/node_modules/request-promise-core/lib/plumbing.js:87:29)\n at Request.RP$callback [as _callback] (/data/node/fulfillment/fulfillmentService/node_modules/request-promise-core/lib/plumbing.js:46:31)\n at self.callback (/data/node/fulfillment/fulfillmentService/node_modules/hubspot/node_modules/request/request.js:186:22)\n at emitOne (events.js:96:13)\n at Request.emit (events.js:188:7)\n at ClientRequest. (/data/node/fulfillment/fulfillmentService/node_modules/hubspot/node_modules/request/request.js:816:16)\n at ClientRequest.g (events.js:292:16)\n at emitNone (events.js:86:13)\n at ClientRequest.emit (events.js:185:7)\n at Socket.emitTimeout (_http_client.js:629:10)\n at Socket.g (events.js:292:16)\n at emitNone (events.js:86:13)\n at Socket.emit (events.js:185:7)\n at Socket._onTimeout (net.js:338:8)\n at ontimeout (timers.js:386:14)\n at tryOnTimeout (timers.js:250:5)\n at Timer.listOnTimeout (timers.js:214:5)”,
“options”:{
“transform2xxOnly”:false,
“resolveWithFullResponse”:false,
“simple”:true,“timeout”:30000,
“qsStringifyOptions”:{“arrayFormat”:“repeat”},
“qs”:{“hapikey”:“XXXXXXXXXXX”},
“url”:“http://api.hubapi.com/deals/v1/deal/244243707”,
“json”:true,
“body”:{“properties”:[
{“value”:“Out For Delivery”,“name”:“fulfillment_status”}]},“method”:“PUT”},
“error”:{“connect”:false,“code”:“ESOCKETTIMEDOUT”},
“cause”:{“connect”:false,“code”:“ESOCKETTIMEDOUT”},
“message”:“Error: ESOCKETTIMEDOUT”,“name”:“RequestError”}


#7

I have seen one error come in saying that we have reached our secondary limit. I dont always see this error, mainly just the timeouts. We should be nowhere close to the 10 requests a second that would trigger this.

Would one of these other restrictions be responsible for this?

  • Integrations that poll HubSpot for new or updated information are limited to polling for those changes at intervals of 5 minutes or more.
  • Requests resulting in an error response may not exceed 5% of your total requests.

#8

Hi @RJ_Forbes,

I don’t believe the timeouts are coming from HubSpot; generally we return 502 or sometimes 4xx errors when requests time out on the HubSpot side. It sounds like this is related to Node concurrency; have you checked out any of the other answers/related topics on the stack overflow article I posted? PUT requests tend to take (slightly) longer than other requests; could there be an aggressive timeout setting somewhere that’s failing these requests?


#9

Timeouts were occurring after 30 seconds (I had increased from 15 to 30 ).

I added some more verbose error logging and now I am seeing the secondly limit error.
“You have reached your secondly limit.”

We do have a few different services hitting the hubspot API. Is it possible that we are getting timeouts on some requests as the secondly limit is being hit from a different request?

Also, is there any logging on hubspot that we can see the requests that are being sent? Im only seeing at most 1-2 per second but usually 2-3 over 10 seconds with a total of about 300-500 requests total per day. At this rate it seems odd we would be going over limit.


#10

Hi @RJ_Forbes,

Interesting; I wouldn’t expect timeouts like this to occur if you hit your secondly limit unless perhaps the 429 responses are preventing some callback/promise from executing/resolving? Even very low volume apps can hit the secondly limit if there’s no logic in place to enforce the 10 req/s limit. There’s API call logging built into your developer portal, but that only works if you’re using OAuth to authenticate your requests. If you’re using a hapikey, you can send me your portal ID and I can see if I can dig up some info on your requests.


#11

HI @Derek_Gervais I have messaged you our Portal Id and have also done some testing off our network over the weekend, I can trigger a socket timeout by requesting recent deals consistently. I have a page that displays the last 5 deals created and just refreshing this page 4-5 times over a few seconds can cause a timeout.