Two folders in a Postman collection share a name — which one does Newman's `--folder` run?
answer
- No error and no prompt is raised
- Exactly one subtree becomes the entry point
- Shallower beats deeper in the search
- Then position in the item array
- A passing run of the wrong subset
basics
~10 sThe first match wins and only it runs. Newman's --folder lookup compares ids and names and takes own children before deeper ones, so a top-level folder beats a same-named folder nested further down.
solid answer
~40 sNothing arbitrates between duplicates. The value goes to the runtime as `entrypoint.execute` and the default `idOrName` lookup walks the collection's `item` tree, accepting the first entry whose id or name equals it. Two folders called `Smoke` produce no error, no prompt and no double run — exactly one of them becomes the entry point. Which one depends on traversal order: own children are considered before deeper ones, so the shallower candidate is reached first, and among entries at the same depth the earlier position in the `item` array wins. The dangerous part is that this looks entirely healthy from outside: the run executes, assertions pass, and only the request count betrays that the wrong subtree ran. Passing an id, or keeping names unique file-wide, is the fix.
go deeper
Remember the headline: with two same-named folders only one runs, and no error tells you which. Be able to say that the first match wins rather than guessing that both run.
Explain the tie-break precisely — ids and names compared under one walk, own children before deeper ones, then position in the file's item array — and note that the search stops at the first hit.
Show why this is an operational defect: a mis-resolved selection produces a clean-looking run of the wrong subset, so the check is what executed, not whether it passed.
Own the policy angle: names used in command lines are identifiers, so file-wide uniqueness and rename review are worth enforcing on a collection many people edit.
## The short rule Nothing arbitrates between duplicates: **the first entry the lookup reaches wins, and only that one runs.** A `--folder` value is handed to the execution engine as `entrypoint.execute` and resolved by the default **`idOrName`** strategy, which searches the collection's `item` tree and accepts the first entry whose **id** — or, failing that, whose **name** — equals the value. Two folders called `Smoke` do not raise an error, do not prompt for a choice, and do not both run. ## Own children before deeper ones Traversal order is what decides which duplicate you get, and it is the one detail candidates miss. The lookup considers **an entry's own children before descending into them**, so the shallower candidate is reached first: - a folder at the **top level** of the collection beats a folder with the same name **nested inside** another folder; - among entries at the **same depth**, the one appearing **earlier in the file's `item` array** is reached first, because array position is the collection's own order; - ids participate in the same comparison under the same traversal, so an id is not a different search — it is simply a value far less likely to be duplicated; - the search **stops** at the first hit, which is why depth-then-position fully determines the outcome. | Value you pass | Candidates in the file | What runs | |---|---|---| | a name unique in the file | one | that subtree | | a name at top level and again nested | two | the top-level one | | the same name twice at one depth | two | the earlier entry in the `item` array | | an entry's id | one, in practice | that entry, unambiguously | ## Why nothing warns you Resolution is a search that stops at its first hit, so it never learns that a second candidate exists. There is no ambiguity check to report, because from the engine's point of view the value resolved cleanly and the run proceeded normally. From the operator's side the run looks completely healthy: requests are sent, assertions evaluate, a result is produced. That is the whole hazard. **A clean run of the wrong subset looks exactly like a clean run of the right one.** The signal that something is wrong is indirect — the number of requests executed, or a check you were sure existed never appearing in the results. This is why duplicate names in a collection several people edit are treated as a real defect rather than a cosmetic untidiness. ## Making a selection unambiguous 1. **Keep entry names unique across the whole file, not merely among siblings.** The lookup is not scoped to a parent, so "unique within its folder" buys nothing: a same-named entry anywhere else in the tree is still a candidate. 2. **Pass an id when the caller is a machine.** An id is opaque and unreadable in a command line, but it is far less likely to collide, and it removes the depth-versus-position reasoning entirely. It is only as stable as whatever writes the file. 3. **Treat a rename as a contract change.** Every name that appears in a command line somewhere is an interface. Renaming a folder does not break the collection; it breaks the callers that selected it. 4. **Verify what ran, not just that it passed.** Compare the requests actually executed against the ones you expected the subtree to contain. That comparison is the only thing that catches a silently mis-resolved selection. ## The related case worth separating Duplicate names are the *single-value* hazard: one value, several candidates, first one wins, silently. Passing **several** `--folder` values behaves differently — the lookup switches to its multiple-value form, where every value must resolve and one that does not takes the entire run down. Do not blend the two in an answer: one duplicate name gives you the wrong subtree quietly, while one unmatched name in a multi-value selection gives you no run at all. ## What to say in an interview Lead with the rule — first match wins, no error, exactly one subtree — then give the tie-break: own children before deeper ones, then position in the `item` array. Finish with the consequence rather than the trivia: because the lookup is name-based and file-wide, folder names in a shared collection are effectively public identifiers, and treating them as free-form labels is what produces a run that passes while testing the wrong thing.
- How would you detect that a `--folder` selection resolved to the wrong duplicate?By checking what ran, not whether it passed. Compare the executed request names and count against the subtree you expected to select. A silently mis-resolved run is otherwise indistinguishable from a correct one, because resolution stops at the first hit and reports no ambiguity.
- Does passing an entry's id instead of its name change the search?Not the traversal, only the collision odds. Ids and names are compared under the same walk and the first match still wins; an id is simply far less likely to be duplicated. The cost is readability — a command line carrying an opaque id tells a reviewer nothing about what it selects.
It behaves like calling out a first name across an open-plan office: the nearest person who answers is the one you get, and nobody tells you a second person has the same name.
saying these in an interview costs you the question
- Says the run fails or prompts when two names collide
- Claims both same-named folders execute in sequence
- Thinks the deepest or last matching entry wins
- Assumes uniqueness among siblings is enough for the lookup
- Treats a passing run as proof the right subtree ran