Alternative way to detect if running from Collection or Send (reopened)

[ngiraud-aareon (Nicolas)]

Hi all.

I’m posting this topic to reopen this one: Alternative way to detect if running from Collection or Send

I am having the exact same problem on my collection, and I can confirm that calling postman.__execution.cursor.length is triggering the warning message 'Using "postman.setNextRequest" is deprecated. Use "pm.execution.setNextRequest()" instead.', and that, even though I am never calling postman.setNextRequest.

Therefore, there are 2 issues that are still not fixed and I really wish this topic will not be closed for inactivity in 30 days…

1. There are currently no alternative way to check that the current run is from a Collection or just a single “Send”. Please add a way to do that without relying on a deprecated global variable again.
2. Please fix the deprecation message that is incorrect when calling postmal.__execution.

Thanks a lot.

[danny-dainton]

Hey @ngiraud-aareon

Welcome to the Postman Community!

I’m just trying to establish some context, are you looking to share the information about how a Collection was run?

We have the Runs section at the Collection level to show how the Collection was initiated. From here you can see the it was either run from the Collection Runner or the Postman CLI:

We also have the History option in the left sidebar that show the requests were either send individually or via the Runner.

[ngiraud-aareon (Nicolas)]

Hello @danny-dainton and thank you for your reply.

I’m sorry I did not add some context as I thought the original topic was already giving some. Let’s clarify the content here.

The context

I have a collection with some requests. Into one of those requests, there is a Pre-request script defined, and this pre-request script is programmed in order to have the request to behave differently from whether I just send the request by clicking the “Send” button, or if the request is executed through a collection run I either started with the “Run” button or using Newman to run my collection. This context is what I want, and what I already have, but…

To programmatically know the behavior I want the request to follow, my pre-request script is something like this:

if (postman.__execution.cursor.length > 1) {
  // Behave like we are in a collection run.
} else {
  // Behave like we click on "Send" button.
}

Like I said, this perfectly works and does exactly what I want. But there are 2 problems :

Problem 1

First problem is that using postman global variable is deprecated, so I would like to have another variable that does exactly the same than postman.__execution.cursor.length without relying on a deprecated variable. To be clear, I want to replace the pre-request script I just described above with

if (variable.I.could.use.to.do.the.same > 1) {
  // Behave like we are in a collection run.
} else {
  // Behave like we click on "Send" button.
}

Problem 2

Second problem is that when I run the collection using Newman, I can read this log message when my pre-request script is executed:

  ┌
  │ 'Using "postman.setNextRequest" is deprecated. Use "pm
  │ .execution.setNextRequest()" instead.'
  └

And to be clear: I replicated this problem by running a collection of a single request only containing postman.__execution.cursor.length in its pre-request script via Newman, nothing more, nothing less, and the log message was triggered.

Expectations

The second problem is creating confusion because it is said that postman.setNextRequest was called, while this is not true, it was postman.__execution.cursor.length. But the first problem is maybe the one I’m expecting a solution the most: as soon as I have a non-deprecated variable that does the same, the second problem should not occur anymore.

I hope I was clear enough. If I wasn’t, please feel free to tell me which part exactly on my message you don’t understand so I could enlight you.

Have a nice day

[ngiraud-aareon (Nicolas)]

I keep this topic opened in order for it not to be closed in the next days. I’m still expecting an answer about it, now I made it clear.

Hoping to read an answer,

Regards,

[danny-dainton]

The topic will stay open for now, the other category had an auto-close setting enabled after a certain number of days, which isn’t the case here.

I’ve reached out to the team for a bit more detail. From what I understand, there isn’t a direct alternative to postman.__execution.cursor.length. It was more of a temporary workaround for a specific context using that legacy postman sandbox API rather than a permanent solution.

I’ll also get the warning message checked to understand why it’s mentioning setNextRequest in the log. Just to confirm, are you only seeing that with Newman, or does it appear in the Collection Runner as well?

If this is something you’d like to see supported, the best next step would be to raise a feature request on our GitHub tracker here:

Build software better, together

That way, the team can review it for future improvements.

[ngiraud-aareon (Nicolas)]

Thank you very much for your answer.

Just to confirm, are you only seeing that with Newman, or does it appear in the Collection Runner as well?

I can only see that with Newman, I can’t find any log about this wrong deprecation message in the logs of the Collection Runner, nor in the console.

I’ll raise a feature request about it, as removing the access of postman variable (because deprecated today) in the future will lead to a complete breakdown of my collections, if it ever occurs. Thanks for linking me the GitHub tracker.

EDIT: in order to keep track of this, here is the GitHub issue created about it: Provide a programmatical way to know if the request is run from a collection run, or in standalone · Issue #13882 · postmanlabs/postman-app-support · GitHub

Have a nice day,

Regards,

[danny-dainton]

Thank you for raising that feature request.

The full postman object will be removed from the sandbox. It has been marked as deprecated for more than a year to give everyone time to move to the newer API, and while there is no set date for its removal yet, it would be wise to prepare for this change now rather than when it disappears unexpectedly.

Both the sandbox and the console include notices to help users understand that the legacy syntax is deprecated.

The postman.__execution.cursor.length function you are using is part of that legacy object and works only as an informal workaround. As it is not part of any officially supported guidance, we would not recommend relying on it for future workflows.

[ngiraud-aareon (Nicolas)]

You are definitly right about it. The thing is, there is currently absolutely no other way to find out, in pre-request script for handling different programmatic behaviors, if the context of the run is from a Collection or a standalone “Send” clicked-button. That’s why the feature request I sent is important IMO: if you remove the postman variable in a close future, you will remove some API functionnalities rather than moving them.

Hoping to see my feature request being updated on GitHub in the next days .

Regards,

[danny-dainton]

@ngiraud-aareon

I have a collection with some requests. Into one of those requests, there is a Pre-request script defined, and this pre-request script is programmed in order to have the request to behave differently from whether I just send the request by clicking the “Send” button, or if the request is executed through a collection run I either started with the “Run” button or using Newman to run my collection.

Could you expand more on what it is that changes between it being run from a single request over running in a pipeline?

There is always more than one way to achieve something, potentially there could be a different approach here that doesn’t involve a deprecated or a new function.

[danny-dainton]

This is by no means a solution but could using something like this in the Newman command:

--global-var "runFrom=newman"

And this using this in the script logic:

if (pm.globals.get('runFrom') === "newman") {
  // Behave like we are in a newman run.
} else {
  // Behave like we click on "Send" button.
}

That’s obviously quite limited to newman vs individual request but something along those lines.

[ngiraud-aareon (Nicolas)]

Thanks for your proposal.

Could you expand more on what it is that changes between it being run from a single request over running in a pipeline?

Our requests are oftenly lying on other requests that are in another collection we called “Common Requests” within the same workspace. We do have a library executed in pre-request scrips at collection level we are using to dynamically replace (or prepend) the current request by one of the “Common Requests” in the run.
When in “run from single request” mode, such replace cannot happen as Postman (through pm API) does not allow us to run another request additionnaly (at least, not using the mechanics of Postman), so we need to play a workaround that, most of the time, makes ignoring the current request.
When in “run in a pipeline” mode, we can programmatically interfer with the current collection run (as there is a collection run) to prepend or replace the current request with one of the “Common Requests” collection. That is something we can both do by running a collection run from postman UI, or using Newman.

Having a global variable === "newman" could be OK, as long as we are always using Newman to run a collection… which might be false in lots of cases (local development, benefit of using a clear Postman UI, ability to run a portion of the collection instead of whole, …). Anyway, thank you for proposing something. We might need to see how to proceed in another ways to try to stop relying on postman deprecated variable.

[danny-dainton]

I might be wrong in my understanding here but have you taken a look at the new pm.execution.runRequest() method.

As it looks like your calling other requests from different Collections, it might be worth checking out. I recently demoed this at an event and created a Public Collection.

If you take a look at the pre-request/post-response scripts in this request if shows how that runRequest method could be used to call other requests in different Collections.

A point to note, this would only work with the Postman CLI and not Newman. It’s basically the same tool in many ways but with updated features and a few new things packed in there.

---

With using a command flag like --global-var you will know it’s alway run from CI as you couldn’t add that in the same way through the UI. You could have a runFrom variable with runner or something like that which is permanent but gets over rided by the CI flag when run outside of the Postman UI.

This all makes more sense in my head, I haven’t actually demoed any of it out