How does a Postman run resolve the name given to pm.execution.setNextRequest, and what happens when nothing matches?

## What resolution has to solve When a script records a target with `pm.execution.setNextRequest`, it hands over a **string**. The run, meanwhile, is a flat ordered sequence of **items** — each item being a request plus its scripts — and the runtime must turn that string into a **position** in that sequence before it can seek the cursor. It does so by preparing a lookup over the items the run contains, then asking that lookup for the value it was given. ## Ids before names The lookup is consulted **id first, then name**. Every item in a collection file carries both an `id` and a `name`; the `name` is the human label you see and type, the `id` is the stable identifier stored beside it. The consequence: - a value that matches an item's `id` resolves to that item, even if some other item's `name` is the same string; - a value that matches no id falls through to the name match; - a name is only ever a fallback, which makes ids the precise way to address an item and names the convenient one. | Value you pass | Resolves to | |---|---| | An item's id | That item, ahead of any name match | | An item's name, no id match | The item with that name | | Neither | The end of the iteration | | `null` | The end of the iteration | Names are also not guaranteed unique. Nothing stops a collection from carrying two requests called `Get order`, and a string cannot address both — which is a reason to keep target names distinctive rather than descriptive. ## The failure mode: a typo ends the run silently This is the fact the leaf exists to teach. An unmatched value does **not** raise a script error, does **not** log a failure against a test, and does **not** fall back to "just carry on in file order". It sets the position to the **end of the iteration**, which is precisely what passing an explicit `null` means. The observable result: 1. The current item finishes normally — its request is sent, its assertions run and pass. 2. The runtime reads the recorded target and resolves it to the iteration end. 3. Every remaining item is never executed at all. 4. The report shows a short run in which nothing failed. Because "nothing failed" and "nothing ran" look alike in a summary that counts failures, a one-character typo can quietly remove most of a suite's coverage while the run is still reported as green. The same shape appears when a target is computed rather than literal — a value assembled from a response field, or a name that was renamed in the collection while the script that points at it was not. ## `null` is the deliberate version of the same thing Passing `null` is not an error path; it is the supported way to say **stop here**. That is why the two cases converge: an unmatched string and an explicit `null` produce the same position. Useful when a response tells you there is no point continuing — a fatal precondition, an exhausted page set, a run whose remaining items only make sense after a step that did not happen. It is worth being explicit about the difference between the two anyway, because they mean opposite things to a reader: - `setNextRequest(null)` reads as *I decided to end here.* - `setNextRequest("Get Ordr")` reads as *go to that request* and behaves as *end here.* ## How to keep it from biting - Prefer distinctive target names over descriptive ones that repeat across folders. - Treat the target as data: derive it from one place, not from a literal repeated in five scripts. - When a run is short, check the recorded targets before you suspect the network, the environment or the assertions. - Assert the outcome your route was supposed to reach. A run that ends early still passes every test it ran; only a check on the destination catches the miss. - When a request is renamed, treat every script that names it as part of that change. ## The mental model to carry The seek is a **lookup with one fallback and no error state**. Ids beat names, an unmatched value is not a mistake the runtime will tell you about, and the position it lands on is the same one `null` asks for. Everything painful about this mechanism follows from that single design choice.