How to test/assert ECONNRESET in my Test script

Hello, I have been executing some bulk actions using the Collection Runner and during some runs, our web server backend suffered a glitch which resulted in Postman reporting ECONNRESET. The glitch recovered itself and is being investigated, but I want to improve my test and assertion flow to handle the issue should it occur again in my sequences.

I submitted a support request and receive the following response, which does not quite provide an answer: “Because this is a node-level error, Postman doesn’t have a way to detect it by scripting (test logic). The reason is that with this error, there will be no response to test in pm.request, pm.response, or responseCode”

Personally, I don’t quite believe the answer; there must be a way. It just has to be different to a normal HTTP Status Code test/assertion.

It is a rare and intermittent issue, so it isn’t something I can reproduce easily, so asking if anyone else has any suggestions.

Here are some things I already do, or am exploring:

  1. My scripts already assert for a successful response using pm.test (… { pm.response.to.not.be.error }) and in the case example, this assertion did fail.

  2. Might I see something in a variable such as pm.response.error? I observe that on a successful request, pm.response.error is undefined; but I cannot find any documentation or tickets that list viable values that this property may return.

  3. I could test for the absence of a property, for example: pm.has.response . (This syntax errors in the successful response case, so probably not)

My instinct tells me #2 is the most likely, but I just don’t know what value to assert against.

ECONNREST is a catastrophic error.

It’s a server error, but not one that has failed with a proper response code.

ECONNRESET means that the TCP conversation abruptly closed its end of the connection.

It’s a node JS thing, and Postman is built on node.

Therefore as explained, there will be no response for PM to test against.

Debugging these errors is normally case of checking the server logs.

OK, so what I think that you are saying is that if I find that pm.response simply is undefined, then I might not be able to specifically diagnose that it is an ECONNRESET condition, but I might still be able to handle it.

What I basically want to do is detect the negative condition, pause that iteration for some amount of time, then re-run the current request and hopefully it will be successful with the server glitch having recovered, and resume other API calls in that iteration. (Limiting the total number of retries, just in case something more severe happened)

I know that I can find the problem in the server logs; that’s how I diagnosed it was a server glitch in the first place. I just want to be more resilient about it.

ECONNREST is the node way of handling this, but it is a serious error.

You’ve already pin pointed that undefined won’t specifically call out this issues, but may be of some use.

You could maybe submit a Postman feature request to maybe fail a bit more gracefully on ECONNREST errors. (but this really is a server side issue, so this probably won’t be a priority).