A Postman request fails a test that is not in its own script tab — how do you find the script's owner?

## The symptom and what it actually means The report always sounds the same: a request shows a test result — usually a failing one — and its own script tab is empty, or contains nothing that could produce that name. Someone edits the request, re-runs, and the result is still there. The instinct that the request must be hiding something is the wrong one. The correct reading is structural. Scripts hang on **containers**, not only on requests. A script saved on a folder or on the collection itself runs around every send beneath it, and it stays saved on that container — it is never copied into the requests it covers. So a request can execute several scripts it shows no trace of, and "the request's script tab is empty" says nothing at all about how many scripts ran. ## Why it is invisible from below Three properties of the model combine into this blind spot: - **Inheritance is by position.** A request is covered because of where it sits in the tree, not because of anything recorded on it. Nothing is written into the request when a folder gains a script. - **Inherited scripts accumulate.** They do not resolve to a single nearest owner, so finding one ancestor with a script does not mean you have found the only one. Keep walking to the root. - **The same script body runs under many requests.** Reading the ancestor's script tells you what runs, but not which of several similar scripts you are currently watching execute. ## The diagnosis, in order 1. **Walk the ancestors, root-ward.** Open the folder the request sits in, then each folder above it, then the collection itself, and read every script saved on them. Do not stop at the first hit — collect all of them. 2. **Assume every one you found is running.** The list executes ancestors first and the request's own last, so an inherited script has already run by the time the request's own would. 3. **Confirm the owner from inside the run.** `pm.execution.location.current` names the owner of the script that is currently running. When two folders carry near-identical scripts, or when a copied script exists at two levels, this is what tells you which one produced the behaviour, and reading it is faster and safer than deleting scripts one at a time to bisect. 4. **Reproduce the boundary.** Run a sibling request under the same ancestor and a request outside it. If the sibling shows the same result and the outsider does not, you have located the owning container, because reach follows nesting exactly. 5. **Fix where the script lives.** Edit the container that owns it. If only one request must be exempt, either guard inside the ancestor's script or move that request out of the subtree; editing the request's own tab cannot alter what it inherits. ## Reading the evidence | What you observe | What it points at | |---|---| | The whole folder shows the result; requests outside it do not | a script on that folder | | Every request in the collection shows it | a script on the collection root | | Only some requests under the same folder show it | one inherited script that branches internally | | Clearing the request's own script changes nothing | the behaviour was never in the request | | The result follows a request after you move it | the new parent owns a script too | The fourth row is the one that ends the argument. Inheritance is unconditional for everything in the subtree, so partial coverage never means "some requests escaped the folder's script" — it means the script ran for all of them and its own logic took different paths. ## Judgment, not just mechanism The production lesson behind this question is about **attribution**. A shared script is a genuine benefit — one place to maintain, automatic coverage of new requests — bought at the cost of a request that cannot explain its own behaviour to whoever opens it. Teams that hoist convenience scripts to the collection root without thinking about it end up with failures nobody can attribute, because the only artefact the reader has in front of them is the request. Two habits keep it manageable: - **Name the level in the behaviour itself**, so that anything an inherited script produces carries the owner it came from rather than arriving anonymously. `pm.execution.location.current` exists precisely because "which request is running" and "which script is running" are different questions. - **Prefer the narrowest container that covers the need.** A script on the one folder that requires it has a blast radius you can hold in your head; the same script on the root does not. The interviewer is checking whether you reach upward instinctively when a request behaves in a way its own contents cannot explain — and whether you know that emptying the request's script tab is not a diagnostic step at all.