skip to content

In Newman, what happens when several `--folder` values are given and one matches nothing?

level: seniorimportance: must knowfreq 45%

answer

  1. The option is repeatable, values collected
  2. Several values change the lookup form
  3. Every value must resolve first
  4. No partial run of the matched ones
  5. Loud no-start, not a quiet subset

basics

~10 s

The whole run aborts. Several --folder values switch the entry-point lookup to its multiple-value form, which requires every value to resolve, so one unmatched name prevents even the matched folders from running.

solid answer

~40 s

`--folder` is repeatable, and passing it more than once changes the resolution strategy rather than merely adding entries. One value uses the default `idOrName` lookup; several switch it to `multipleIdOrName`, which resolves the whole set before anything executes. The consequence is all-or-nothing: **one value that matches nothing aborts the entire run**, and the folders that did resolve are not run as a partial subset. There is no nearest-name matching, no skipping with a warning, and no "run what you can". Operationally this makes a stale name in a long selection list expensive — one folder someone renamed in the shared collection takes down every other selection in the same command — which is the argument for keeping selection lists short and names stable.

code

bash · 1 line
bash
newman run collection.json --folder "Auth" --folder "Checkout" --folder "Chekout Extras"

go deeper

for a junior

Know that --folder can be passed more than once, and that a value which matches nothing is fatal rather than ignored. Do not expect the run to carry on with whatever matched.

for a middle

Explain the mechanism: one value uses the default id-or-name lookup, several switch to the multiple-value form that resolves the whole set before executing, so resolution is all-or-nothing.

for a senior

Show the operational reasoning — why loud refusal beats a clean verdict over an incomplete run, and how to keep one stale name from taking down every selection in an invocation.

for a principal

Own the trade: fewer values per invocation reduces blast radius but multiplies invocations, and renames in a shared collection are breaking changes whose cost this behaviour makes total rather than partial.

## What passing several values changes `--folder` may be given more than once on a command line, and the values are **collected** rather than overwritten — a later value does not replace an earlier one. What is easy to miss is that this changes more than the number of entry points: it changes **how the values are resolved**. - With **one** value, resolution uses the default **`idOrName`** lookup: find the first entry whose id or name equals the value, and start the run there. - With **several** values, the lookup switches to its multiple-value form, **`multipleIdOrName`**, which resolves the **whole set** of values against the collection before anything is executed. That switch is the entire subject of this question, because the two forms fail differently. ## The failure is all-or-nothing Under the multiple-value form, **every value must resolve**. One value that matches no entry — a typo, or a folder someone renamed in the shared collection — **aborts the whole run**. The folders that did resolve perfectly well are **not** executed as a partial subset. Nothing is sent. | Command line | One value unmatched | Result | |---|---|---| | a single `--folder` value | the only value | run does not start | | several `--folder` values | one of them | run does not start; matched ones do not run either | | several `--folder` values | none | the matched entries define what runs | Things that explicitly do **not** happen: - the unmatched value is **not** skipped with a warning while the rest proceed; - it is **not** matched to the nearest similar name — the comparison is equality against an id or a name, with no fuzzy form; - the run does **not** fall back to the whole collection, and does not fall back to the collection's first folder; - later values do **not** overwrite earlier ones, so "only the last one counts" is wrong. ## Why all-or-nothing is the defensible design The alternative is worse. If an unmatched value were skipped, a command line asking for four subtrees and silently running three would produce a **clean result for an incomplete run** — the exact failure this tree keeps returning to, where a passing verdict covers checks that were never executed. Refusing to start is loud, immediate, and impossible to mistake for success. The cost is blast radius: one stale name costs you every other selection in the same invocation. ## Operating with it 1. **Keep selection lists short.** The more values one command carries, the more names must stay valid simultaneously for it to run at all. 2. **Prefer separate invocations when selections are independent.** A stale name then costs one selection instead of all of them. The trade is more invocations to manage. 3. **Treat folder names in a command line as an interface.** A rename in the collection is a breaking change for every caller that names it, and the multiple-value form makes that break total rather than partial. 4. **Make "never started" distinguishable from "ran clean".** Whoever consumes the result must be able to tell an aborted selection from a healthy run. How the runner signals a run's outcome to its caller is a separate subject; what matters here is that the two states are genuinely different and must not be collapsed. ## Diagnosing it in the wild The symptom is characteristic: a command that worked yesterday now runs **nothing at all**, immediately, without sending a single request. That immediacy is the clue — a failure during resolution happens before any HTTP call, so there are no partial results to inspect. Read the values in the command line against the collection's current entry names, and expect the culprit to be the one nobody thought about: a folder renamed for clarity, a value carrying trailing whitespace, or a name whose casing changed. Equality is equality, and none of those near-misses resolve. ## What this is not This is not the duplicate-name case. Duplicates are a **single-value** hazard, where one value has several candidates and the first one quietly wins — you get a run, just of the wrong subtree. The multiple-value case inverts that: you get **no run at all**, loudly. Being able to separate the two — quiet wrong-subset versus loud no-start — is what a senior answer here sounds like.

  • Why is refusing to start better than skipping the unmatched value with a warning?
    Because skipping produces a clean verdict for an incomplete run. Three of four subtrees passing looks identical to four passing, and the checks that never executed cannot fail. Aborting is loud and immediate, so the operator learns at once that the selection is stale rather than discovering it after shipping.
  • How do you limit the blast radius of one stale folder name?
    Keep selection lists short and split independent selections across separate invocations, so a stale name costs one selection rather than every one in the command. Treat renames in the shared collection as breaking changes for callers, and check command lines against current entry names when folders are reorganised.
  • Does the order of several `--folder` values decide anything about the run?
    Do not claim it does. The measured behaviour is the strategy switch and the all-or-nothing resolution; the safe statement is that each matched value contributes its subtree. Inside any one selected subtree, order is the collection file's own arrangement of `item` entries, which selection never rearranges.

saying these in an interview costs you the question

  • Says matched folders still run and the bad one is skipped
  • Thinks a misspelt value is matched to the nearest name
  • Claims the last --folder value replaces the earlier ones
  • Expects a fallback to the whole collection when one value fails
  • Cannot separate this from the quiet duplicate-name case