HTTP exception "ECONNRESET"

General
1

I have daily instabilities with http requests in a node red docker container running in azure. So much so I wrapped http request node in a retry subflow. This usually worked, however after I made a lot of changes, I now get ECONNRESET as an exception which bypasses the entire retry logic. Because I filter statusCode on output msg and to to retry from there.

I made a lot of changes including restructuring of the subflow and upgrading to NR v4.0.9. So unsure what exactly changed the behavior. This is an excerpt of the msg (logged to file for convenience):

"error": {
    "message": "RequestError: read ECONNRESET",
    "source": {
      "id": "733cb730917372cc-04d357fffaef5001-c0c495ea6350d5ae-8ffc9f12f7f0913a-2d874e4ac27c28f3",
      "type": "http request",
      "name": "http request",
      "count": 1
    },
    "stack": "RequestError: read ECONNRESET\n    at ClientRequest.<anonymous> (file:///usr/src/node-red/node_modules/got/dist/source/core/index.js:790:107)\n    at Object.onceWrapper (node:events:639:26)\n    at ClientRequest.emit (node:events:536:35)\n    at emitErrorEvent (node:_http_client:104:11)\n    at TLSSocket.socketErrorListener (node:_http_client:518:5)\n    at TLSSocket.emit (node:events:524:28)\n    at emitErrorNT (node:internal/streams/destroy:170:8)\n    at emitErrorCloseNT (node:internal/streams/destroy:129:3)\n    at process.processTicksAndRejections (node:internal/process/task_queues:90:21)\n    at TLSWrap.onStreamRead (node:internal/stream_base_commons:216:20)"
  }

Has the http node changed behavior? Not sure how I can trigger this problem locally (I have never got this error outside azure). Perhaps add another exception node to listen to http node?

2

The reset is happening on the remote end, so I would start there.

1 Like
3

Thanks for reply! Remote is Thingsboard Cloud (online service) and I have no access to that backend. However, this only happens in the node red running in azure, but virtually never on several node red docker containers running on edge (local / physical / not cloud).

Equally often I used to get ETIMEDOUT, however this seems to now be replaced by "no response from server". The change in http error handling is a nuisance to me because I have to add manual mapping in each case, and I don't know what is what until they occur in production :frowning:

As you can see I had to add a new separate catch in order to deal with this:
image
And also custom exception mapping which is not very robust:

const exceptions = {
  ECONNRESET: "ECONNRESET",
  ETIMEDOUT: ["ETIMEDOUT", "no response from server"],
};

function matchException(text) {
  if (!text) {
    return null;
  }
  for (const key in exceptions) {
    const value = exceptions[key];
    if (Array.isArray(value)) {
      // array
      for (const item of value) {
        if (item.includes(text) || text.includes(item)) {
          return key;
        }
      }
    } else {
      // string
      if (text.includes(value) || value.includes(text)) {
        return key;
      }
    }
  }
  return null; // no match
}

const error = matchException(msg?.error?.message);
if (error) {
  msg.statusCode = error;
  delete msg.logMessage;
} else {
  msg.statusCode = "UNKNOWN";
  let errorPart = "'msg.error' not found.";
  if (msg.error) {
    errorPart = `'msg.error': '${JSON.stringify(msg.error)}'.`;
  }
  msg.logMessage = `ERROR: Caught exception (http retry). Unknown status code. ${errorPart}`;
}

return msg;

And finally log unknown exceptions so I can add mapping to them.