A Postman collection run ends early after item three with every test green — how do you diagnose it?
answer
- Nothing failed because nothing ran
- Suspect routing before the network
- The last recorded target is the one
- A rename breaks a script that names it
- Assert the destination, not just the steps
basics
~10 sSuspect the routing before the network. A recorded next-request target matching no item, or an explicit null, sets the position to the iteration end, so the run stops with nothing failed and coverage missing.
solid answer
~40 sA short run with no failures is the signature of a **routing miss**, not a crash. When a script records a next-request target that matches no item id or name — a typo, a renamed request, a value computed from a response — the position is set to the **end of the iteration**, which is exactly what an explicit `null` does, and nothing is reported as an error. So diagnose in this order: find every script on item three that records a target, compare the string it passes against the target item's real name or id, and remember that the **last call wins**, so a second call may be overwriting the one you are reading. Then close the hole: assert the run reached its destination, because tests that never ran cannot fail.
go deeper
Be ready to recognise the symptom: a run that ends early with nothing failed usually means a script sent it somewhere that does not exist, not that the requests broke. Know that no error message is produced.
Explain the mechanism behind the symptom — an unmatched target or a null lands the position at the iteration end — and walk the lookup order, ids before names, that decides whether a target matched at all.
Demonstrate the diagnosis end to end: find every recorded target, apply last-call-wins, compare against the real item, and then close the hole with an assertion on the destination so a truncated run cannot report green.
Own the reporting question. Decide what a green result must mean for this suite, and what the pipeline should measure — coverage actually executed, not failures counted — so silent truncation cannot pass as success.
## Why "green and short" is its own failure class Most run failures announce themselves: an assertion fails, a request errors, a count goes red. This one does the opposite. The run finishes early, everything that executed passed, and the summary reports no failures — because there were none. The items that would have failed simply never ran. That is worth naming as a class, because the instinct on a short run is to suspect the environment, the network or a slow dependency, and none of those produce this shape. A timeout leaves a failed item behind. A transport error leaves an error behind. A routing miss leaves **nothing** behind. ## The mechanism that produces it A script can record a target with `pm.execution.setNextRequest`, and when the current item finishes the runtime resolves that target to a position and seeks the cursor there. The resolution is a lookup consulted **id first, then name**, and it has no error state: | Recorded value | Where the cursor lands | |---|---| | A real item id | That item | | A real item name, no id match | That item | | A string matching neither | The end of the iteration | | `null` | The end of the iteration | The last two rows are the bug. An unmatched value is not rejected, not warned about and not ignored — it lands the run exactly where a deliberate stop lands it. ## The diagnostic order 1. **Confirm where it stopped, not where it failed.** Establish the last item that executed and note that it completed normally. A clean last item plus missing successors points at routing rather than at the item itself. 2. **Find every recorded target on that item.** Both of its scripts can record one, and a script hung on an ancestor can too. Collect all of them before reasoning about any one. 3. **Apply last-call-wins.** The target is a single slot, not a queue, so the value that matters is the one written last during that item. Reading only the first call you find is how this bug survives a review. 4. **Compare the string against the real item.** Character by character, against the target's actual name — or, better, against its id. Renames are the common cause: the item was renamed, the script that names it was not. 5. **Check whether the value was computed.** A target assembled from a response field or a variable can be empty or undefined on the path the run actually took, and an empty string matches nothing. 6. **Rule the alternative in or out.** A dropped request is a different mechanism with a different signature: it removes one send and the run carries on. If the following items ran, you are not looking at a routing miss. ## Closing the hole so it cannot recur silently Diagnosis is the easy half; the run should not have been able to lie in the first place. The durable fixes: - **Assert the destination.** Have the run check that it reached the item or the state the route was supposed to produce. Tests that never ran cannot fail, so only a check on the end state catches a truncated path. - **Prefer ids for targets that matter.** Ids are consulted first and do not change when someone improves a request's label. - **Keep target names distinctive.** Descriptive names repeat across folders; a repeated name is a target you cannot reason about. - **Keep routing in few places.** One script deciding the route is diagnosable; five scripts overwriting each other's slot is not. - **Treat renames as script changes.** Any item named by a script is part of the blast radius when it is renamed. - **Watch the executed count, not just the failure count.** A run whose item count drops without an explanation is the earliest visible symptom of this bug. ## What to say in the interview An interviewer asking this wants to hear you reach for the mechanism rather than for the network. The strong answer names three things: that an unmatched target and an explicit `null` land in the same place; that no error is raised, which is why the report is green; and that the fix is an assertion on the destination, because a suite that measures only failures cannot distinguish "passed" from "never ran". A candidate who starts by re-running the collection and raising timeouts has not understood what the symptom is telling them.
- How do you tell this apart from a run that simply contained fewer items?By where it stopped. A routing miss leaves a complete, passing last item and an untouched remainder that begins exactly at a sequence position. A run that was built smaller never had those items in it at all — a membership question decided before execution, not a cursor that moved during it.
- What single check would have caught this on the first run?An assertion on the destination — that the run reached the state its route was meant to produce. Failure counts cannot see missing coverage, because an item that never executed contributes no result. Checking the end state converts a silent truncation into an ordinary red result.
- The target string is built from a response field. What extra failure mode does that add?The field can be absent, empty or undefined on the branch the run actually took, and an empty value matches no item — so the run ends at the iteration end just as a typo would. Validate the computed value before recording it, and decide explicitly what should happen when it is missing.
saying these in an interview costs you the question
- Blames the network or raises timeouts first
- Trusts a green report on a truncated run
- Reads only the first recorded target, ignoring later ones
- Expects an error message for an unknown request name
- Confuses a dropped single request with an ended run
- Renames a request without checking scripts that name it