Error: runtime~extractRunnableItems: Unable to find a folder

[luisbriceno (Luis)]

Question regarding Newman CLI 6.1.1, and the –folder [name] feature.
My goal is to call the specific request within a collection.

Based on the following command:

newman run "collection_file.json" -e "environment_file.json" --folder [name] -r cli,junit --reporter-junit-export

Workspace structure:

Collection/
├── My-Folder/
│   └── request-inside-folder
└── request-outside-folder

When running the command, I encounter the following error:

(node:71992) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
error: runtime~extractRunnableItems: Unable to find a folder or request: "[name]"

Error Note: I’ve replaced “[name]” with both the folder/request names (ex. “My-Folder”, “request-inside-folder”, and “request-outside-folder”) and their respective id’s (ex. 230…-…-…-…-…-…3d3) and all yield the same error.

Any ideas?

[danny-dainton]

Hey @luisbriceno

Welcome to the Postman Community!

You would just need to use the request name with the --folder flag, there’s no need to include the path (e.g request-inside-folder).

This should be fine:

newman run "collection_file.json" -e "environment_file.json" --folder "request-inside-folder" -r cli,junit --reporter-junit-export

The folder flag looks at the Collection and does a string based match against the folders or requests. There’s some quirkiness to it like it wouldn’t be able to pick between duplicate folder or request names and would just run the first one it finds.

[luisbriceno (Luis)]

Hi @danny-dainton,

Thanks for the welcome!

I reviewed the collection_file.json file and extracted the “name” from the request I aimed to trigger, and that worked! However to be more specific, my real goal is to trigger the request using the Request Id instead of the name, as you pointed out, to avoid potential issues.

After looking at the collection_file.json, I saw several fields containing id attributes and saw something interesting. Within the request details, there are both “id” and “uid” fields.

• collection.item.event.script.id – did not work
• collection.item.id – did work, but it’s a shorter version of the collection.item.uid
• collection.item.uid – did not work, but is the same id that appears in Postman

The “uid” is mentioned in the Request Details in the Postman application as ID, this id does not work. Whereas, the id (which appears to be a shorter version of uid) does work, as show in the command screenshot below.

“uid” is being mentioned in Postman application*

I guess with this, are users expected to know that they’ll need to use the shorter version of the “uid” or would programmers be expected to grab the “collection.item.id” instead of the “collection.item.uid”? Or would this be considered a bug?

[luisbriceno (Luis)]

Hi @danny-dainton,

I heard back from the Postman team regarding the inconsistency I mentioned previously, and here’s what they had to say:

@Postman Team

Our internal team have reviewed this and have confirmed that the error is expected when running local collections via Newman. This is due to when the collection is exported via v2 and v2.1, we don’t export the IDs (UID and ID) as part of the collection and v1 has been deprecated.

In this scenario, only the folder name will yield a successful result.

However, if you are fetching it from postman while running, The ID would work as a replacement. You can get the ID by removing the first part (userID) of the folder UID.
I hope this helps to clarify the error. If there’s anything else, please let us know.

It appears that this is a known issue, but it may not be on their roadmap for resolution. So, I’ll need to parse out the “first part (userID)” of the UID for my scenario.

Thank you for everyone’s assistance, really appreciate it!