Error: runtime~extractRunnableItems: Unable to find a folder

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:

├── 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?

Hey @luisbriceno :wave:

Welcome to the Postman Community! :postman:

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.

1 Like

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.

  • – did not work
  • – 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 “” instead of the “collection.item.uid”? Or would this be considered a bug?

Hi @danny-dainton,

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

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!

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.