I am trying to use some conditional routing to skip a request in a collection based on whether certain variables are present earlier in the sequence. In the post-request script, we check for the presence of the variable, and then very simply either route to the next request in the sequence or the n+1 request.
For some reason, when I run this in the manual collection runner, the runner just stops after the request containing the conditional routing, and I can’t figure out why. If I comment out the conditional routing, everything runs smoothly, but using setNextRequest seems to be breaking the flow.
Is this expected behavior in the manual collection runner?
Here is pseudo code from the post-request script. There are no syntax errors in the actual code, and no errors are thrown in the request when we run the collection, it just stops moving to the next request:
Are you sure that the condition is met as expected, are you able to log that out to the console?
Are you using the request name of the id of the request, inside the setNextRequest() method?
What do you mean by manual collection runner, are you just referring to running the Collection using the runner or manually hitting send on the requests?
I don’t think the actual body should matter, this is just illustrative here - the broader point is that regardless of the condition returned, we should be going to either request-3 or request-2, but the runner simply stops after request-1 (with no errors). When I comment out the if/else block, the collection continues on to request-2 and then request-3 in order without issue.
Yes, condition is met (we get a console log from inside the block correctly).
I was using the request ID, but postman GUI automatically shows the name of the request which indicates that it is the correct ID.
I normally trigger these workflows via a webhook request, but in this case I was using “Manual run” of the collection, using up my allocation of “Manual Collection Runner Runs”, I wasn’t sure if this is maybe a specific issue to the manual runs
Yes, it was the same question - I meant to delete the original post after reposting this but it seems I’m not able to do that
Without the real details of the full request, the response body and the full script it’s difficult to be able to correctly replicate what you have in front of you.
It’s obviously easier to try and replicate what you mean for illustration purposes but that’s not what you’re actually running and having an issue with here.
Are you able to share some visual examples of what you have, full app screenshots would help here.
Do you have any other scripts at the Collection or Folder level that might be causing issues with the run? Are all the requests saved? Do you use variables in are of the requests or scripts that might not be resolved correctly?
You might have something in place that you’re not seeing or using something that seems not that noteworthy but could be important to the behavior you’re seeing.
Thanks Danny, I do appreciate you trying to help investigate!
The real request returns html that we parse with cheerio to extract certain values. The purpose of the if/else was to determine whether a specific value was present in the initial returned html: if the value is present, then we can move to step 3. If the value isn’t present, then we need to run another request to retrieve the value in step 2. Attached is the exact code that I had to comment out in order for the collection to proceed. When commented out, it works perfectly, regardless of whether the specific value is present (so its not an issue with saving or otherwise). I added the “const clientRateId” code into this snippet so you can see the exact code, although it is also still running earlier in the request uncommented (so there isn’t a syntax error or otherwise being thrown)
I’m not trying to be difficult about sharing information, the whole point is that the ONLY difference between successfully running the full collection and the collection stopping after this request is the presence of this if/else block, so I was trying to just isolate to the pertinent information.
When you add a dummy condition, one you know to be true or false and nothing to do with your original variable, directly into the if statement - is it going down each of those routes correctly?
Nope, that’s why it was strange. It isn’t an issue of routing to the “wrong” request, it would not route to ANY request - it would not even default to routing to the next request in the collection.
For context as well, I have 20+ different collections that I run with monitors via webhooks, so I am pretty familiar with running collections in postman. That’s why I suspected the issue was some undocumented behavior with Manual collection runs (which I only use when I’m testing a new monitor before pushing it live)
When I hardcode the names, it seems to work as expected but when using the id it doesn’t. We recently added the pm.execution.runRequest() feature which resolves the name based on the id and I’m thinking that it could be impacting this other method. Still testing this out though.
I will try that and report back, I always assumed that using an ID would be more reliable than a name - I duplicate some requests across different collections and these retain the same name, and I wasn’t sure how that would behave so I’ve always resorted to IDs instead
I think it’s likely an issue with the way that Ids are being resolved while using that particular method, we’re looking at and seeing what the issue could be.
If you need a quick fix, you could try the request names but the ids would be better. I’ll share any new information I get from the team.
That would make a lot of sense given the behavior I saw - I assume that if the setNextRequest() resolves to a non-existent / non-eligible request, it would just stop execution.
