Retry a failing request

Hey Guys, the above retry logics work perfectly when running test as a Collection set. However if I run a test manually, it doesn’t execute the setNextRequest.

Is there a way we could make this retry feature working even when manually running just that one test.

For example I have two test cases,

Get Request 1: I expect a jsonObject ‘status’ in the response to have the value ‘Completed’. But until it finally says completed, it can say ‘In process’. So I retry the same request using setNextRequest(Get Request 1) until I see ‘Completed’. And I verify some data.
Note: This is where I have added the above retry logic in Tests section.

Get Request 2: I use one of the data from response from Get Request 1 and hit another endpoint to verify another set of data.

The retry logic I have added on Tests of Get Request 1 works perfectly when I run both the tests together as a Collection. But it doesn’t work when I want to just run the Get Request 1 by itself.

Is there a way I could get this retry to work when I just want to run Get Request 1 manually without running from Collection set?

Hey @sariknpl,

There’s no way to do this on a manually executed request at this time. Postman doesn’t have a retry setting on the request level. Doing a collection run and using postman.setNextRequest is the only way.

1 Like

Hello everyone,

I’m seeing a lot of solutions for when the response code is not 2xx, but I am wondering how to setNextRequest on the condition that an assert statement fails. I am working with a collection that will assign variables that will be checked in a test on another request, and in both requests the response code can still be 2xx even if the assert statement fails.

Is there any way to treat the failed test as a conditional statement to trigger a different action without checking the response code or an exit condition? I am not currently working in Newman, just the application UI.

Thank you!

Hey, @aviation-pilot-52818,

Sure, you can do this. A failed assertion is just a thrown error in JavaScript. You can hook into that with try/catch blocks and do routing based on that.

Example:

pm.test('has firstName property', () => {
  try {
    const response = pm.response.json();
    pm.expect(response.args.firstName).to.exist;
    postman.setNextRequest('on success'); // If the previous assertion passed, this line will execute.
  } catch (e) {
    postman.setNextRequest('on error');
    throw e;
  }
});

Did anyone ever answer StanislavMasarsky 's question? I have the same issue. The retry works perfectly, however at the “test” level, the test is still marked as a failure because the tests for that particular call failed, despite the subsequent retry and success. Is the only solution to wrap the retry logic around the test logic in every single api request? @danny-dainton @michal.robaszewski.j

Did anyone ever answer @StanislavMasarsky question? I have the same issue. The retry works perfectly, however at the “test” level, the test is still marked as a failure because the tests for that particular call failed, despite the subsequent retry and success. Is the only solution to wrap the retry logic around the test logic in every single api request? @kevin.swiber (sorry had to post the same question twice because there is a limit to the number of users that a new user can tag in a post)

Not sure it’s an answer specific to @StanislavMasarsky’s solution but using @aviation-pilot-52818 I simply dropped the throw e; It will still show the retried request but will not report the error as it gets swallowed. For my situation this works fine because I just need to rerun the prior request that gets a random user and try again.

Example:

pm.test('has firstName property', () => {
  try {
    const response = pm.response.json();
    pm.expect(response.args.firstName).to.exist;
    postman.setNextRequest('on success'); // If the previous assertion passed, this line will execute.
  } catch (e) {
    postman.setNextRequest('on error');    
  }
});

Hi,
Thank you for your code extract. I’m new to javascript, and I was wondering why you use an environment variable for collection_tries? Why don’t you just use a local variable, like you do for maxNumberOfTries, for this purpose?
Thanks for any clarification,
Connie

Super helpful, thanks!

1 Like

Thank you! We were having the same problem on a third party API we use, and the notification emails were exhausting to check and see the API was absolutely fine.

1 Like

Hello, I have one additional note. In our case, we use retry mechanism in combination with Postman CLI. We have around 1000 tests and there are some duplicate names (because legacy and new api).
In case of command postman.setNextRequest(pm.info.requestName); in one of our environment we get into situation, that with retry mechanism was executed only 400 tests, but using runner there was executed 1000 tests.
We found that this was because same name of requests, which are failing.
If the test failed on legacy api, it was planed uising requesName as next, but in this time CLI use test from following folder (with same name) not the same test in current folder. In runner is situation different and there was used same test again. We fix this issue by using not requestName but requestId. Its looks like that method postman.setNextRequest accept both the id and name of the following request.

1 Like