How do you stop `--folder` selections against a shared Postman collection from running the wrong subtree?
answer
- Names in a command line are identifiers
- One hazard is quiet, one is loud
- Uniqueness must hold file-wide
- Readable name versus unambiguous id
- Check what ran, not the verdict
basics
~20 sTreat entry names as an interface. Keep them unique file-wide because the lookup is not path-scoped, review renames as breaking changes, keep selection lists short, and verify which requests ran rather than only the verdict.
solid answer
~40 sThe mechanism gives you two distinct hazards and they need different controls. A duplicated name is **quiet**: the lookup takes the first match, so a run executes the wrong subtree and still passes. An unmatched name is **loud**: with several `--folder` values the lookup resolves the whole set first, so one stale name aborts everything. So the policy is (1) uniqueness across the entire file, not just among siblings, because resolution is not scoped to a parent; (2) renames reviewed as breaking changes, since every name a command line carries is an identifier someone depends on; (3) short selection lists, or separate invocations, to cap the blast radius of one stale value; (4) checking *what executed* against what the subtree should contain. Which cases deserve to exist at all is a different discipline.
go deeper
Take away one habit: do not rename folders in a shared collection casually, because command lines elsewhere select them by name and a rename can stop those runs or redirect them.
Be able to explain both hazards mechanically — first match wins for a duplicate, whole-set resolution for several values — and why file-wide uniqueness follows from the lookup not being path-scoped.
Demonstrate the operational instinct: the silent wrong-subtree run deserves more effort than the loud abort, and verification means checking which requests executed rather than trusting the verdict.
Own the interface framing and the name-versus-id trade, and hold the boundary: which checks belong in the pack, and how a result reaches its consumer, are separate disciplines from selection.
## Why this needs a policy at all A collection edited by several people and driven from several places has a property nobody declares: **the names of its folders and requests are identifiers other things depend on.** Every command line that passes `--folder` is a caller, and the collection file is the interface those callers bind to by name. Nothing in the file records that dependency, and nothing checks it when a name changes. Two distinct failure modes come out of the selection mechanism, and mixing them up produces the wrong controls: | Hazard | Cause | How it shows up | |---|---|---| | **quiet** | a name matching more than one entry | first match wins; the wrong subtree runs and passes | | **loud** | a name matching no entry | resolution fails; with several values the whole run never starts | The quiet one is far more dangerous, because a clean run of the wrong subset is indistinguishable from a clean run of the right one. ## The rules worth enforcing 1. **Uniqueness across the whole file, not within a folder.** The lookup is not path-scoped: a same-named entry anywhere in the tree is a candidate, and depth plus position decide which wins. "Unique among its siblings" buys nothing. 2. **Uniqueness across kinds, too.** Requests and folders share one lookup, so a request named like a folder can shrink a run to a single call while still passing. 3. **Rename is a breaking change.** It should go through the same review as changing any other published identifier, with the callers named in the change. Renaming for clarity is exactly how working commands stop running. 4. **Short selection lists.** Every value in a multi-value command must stay valid for any of it to run. Independent selections belong in separate invocations, which caps the damage of one stale name at that one selection. 5. **Verify what executed.** The only check that catches a mis-resolved selection is comparing the requests actually run against what the subtree should contain. The verdict alone cannot catch it. ## Name or id: the real trade Selection accepts an entry's **id** as readily as its **name**, and this is a genuine judgment call rather than a best practice. - A **name** is readable. A reviewer sees the command line and knows what it selects, which is worth a great deal on something people edit by hand. - An **id** is unambiguous. It is far less likely to collide, so it removes the depth-versus-position reasoning entirely — but it is opaque in review, and it is only as stable as whatever produces the file. There is no universal answer. A small collection with disciplined naming is better served by names; a machine-driven selection over a collection whose names churn is better served by ids, provided the file's ids are themselves stable. What is not defensible is choosing without knowing which failure mode you are buying protection from. ## Where this stops being a selection problem Several neighbouring decisions look like this one and are not: - **Which checks deserve to exist, and when to retire the ones that no longer earn their place**, is suite composition and maintenance, not selection. - **What the unit of parallelism should be, and what that unit makes contended**, is an isolation question with its own tradeoffs. - **How the runner signals a run's outcome to whatever invoked it** — the exit-code contract that turns a run into a gate — belongs to the runner as a program. Selection answers one narrow question: *given this file, which entries execute?* Keeping the boundary sharp is itself part of the answer, because teams routinely try to solve a suite-composition problem by adding more folder values to a command line, and end up with a fragile invocation that expresses a structure the collection does not have. ## What a strong answer sounds like Lead with the asymmetry — one hazard is silent and one is loud — and let it drive the controls: uniqueness and verification for the silent one, short selection lists and rename review for the loud one. Then take a position on names versus ids and say what it costs. Finish by naming what you are **not** solving here: which cases belong in the pack, and how the result reaches whoever consumes it, are other people's problems, and treating them as selection problems is how command lines become unmaintainable.
- Which of the two hazards would you spend effort on first, and why?The quiet one. An unmatched name stops the run immediately and announces itself, so it is self-reporting and cheap to fix. A duplicated name produces a passing run of the wrong subtree, which can persist for months and quietly removes coverage nobody notices is missing until the untested behaviour breaks.
- When would you accept opaque ids in a command line despite the readability cost?When selection is machine-driven and names churn faster than the callers can be updated — many jobs binding to one collection several teams reorganise. The condition is that the file's ids are themselves stable; if whatever writes the file regenerates them, ids trade a readability problem for a much worse one.
It is the same discipline as a public method name: the file can be refactored freely, but the moment a name is written down somewhere else, renaming it is an API change rather than tidying.
saying these in an interview costs you the question
- Treats folder names as free-form labels, renamed at will
- Enforces uniqueness only among a folder's own siblings
- Believes a passing run proves the right subtree ran
- Solves suite composition by adding more folder values
- Ignores that a request can win a folder's name
- Assumes ids are stable without knowing what writes the file