In Newman, what runs when a `--folder` value matches a request rather than a folder?

## The answer, and why it surprises people A value passed to `--folder` that equals a **request's** name or id resolves to that request, and the run then consists of **exactly that one call**. The option's name promises folders; the lookup behind it does not restrict itself to them. The reason is structural. A collection file's `item` array is **heterogeneous**: an entry is a folder when it carries its own nested `item` list, and a request otherwise. Both kinds are ordinary entries in the same tree, and the default **`idOrName`** lookup that resolves `entrypoint.execute` compares the value against an entry's **id or name** without asking which kind of entry it found. Whatever it matches first becomes the run's entry point. ## What executes, precisely - The matched request becomes the entry point; **nothing else in the collection is sent**. - There is **no climb to the parent**. Matching a request does not select the folder containing it and does not start the folder "from that request onward". - There is **no expansion to siblings**. A request's neighbours in the same folder are simply not part of the selected subtree. - **First match still wins.** Further entries sharing the name are never reached, whether they are requests or folders. | Value matches | Entry point | Requests sent | |---|---|---| | a folder | that folder | its subtree, flattened, in file order | | a request | that request | exactly one | | a request that shares a folder's name | whichever the walk reaches first | one, or a whole subtree | | nothing | none | none; the run fails to start | ## Why this is useful Re-running a single call from a terminal is a common need — a request failed in a long run and you want it alone, or you are iterating on one script and do not want its neighbours' side effects. Because the lookup accepts a request, that need costs nothing: no temporary folder, no edited copy of the collection, no second file. The selection is expressed entirely on the command line and the collection under version control is untouched. ## Why it is also a trap The same property produces a failure mode that is hard to see: 1. Somebody names a request the same as a folder — `Login` as both a folder of auth calls and a single request inside it is the classic shape. 2. A command line selects `Login` expecting the folder. 3. The traversal reaches one of them first and the run executes **one request** instead of the folder's subtree. 4. The run passes, because the one request that ran was fine. The checks that did not run cannot fail. The defence is the same as for duplicate folder names: keep names unique across the whole file, and verify **which** requests executed rather than only that the run was clean. ## What stays outside this decision Selection answers one question only — *which entries execute*. It does not decide what an enclosing folder or the collection itself contributes to a request that runs inside it; how declarations attach to a request through its ancestors is a separate subject with its own rules. Nor does selection have anything to do with changing the sequence once a run is under way: naming the next request to visit, or dropping the current one, is a different mechanism belonging to the sandbox's execution API. ## How to answer it in an interview Say the fact first — *yes, `--folder` matches a request, and then exactly that request runs* — then give the reason, which is what shows understanding: requests and folders are entries in the same `item` tree and share one id-or-name lookup, so the option cannot tell them apart and does not try. Close with the consequence: it is a genuinely convenient way to re-run one call, and a real hazard whenever a request and a folder in the same collection share a name.