In a Postman script, what does pm.execution.setNextRequest(name) do to a run, and when does it take effect?
answer
- Nothing moves until the item finishes
- It writes a target, not a jump
- One slot, overwritten, never queued
- A seek can point backwards
basics
~10 spm.execution.setNextRequest records a target for the run's cursor rather than jumping. The current item finishes normally, then the runtime seeks to the named request. The last call made during that item wins.
solid answer
~40 sIt is a **deferred cursor seek**, not a `goto`. Calling `pm.execution.setNextRequest` in a Postman script writes a target into the execution's state and returns immediately: the rest of the script runs, the request is still sent, and the item's test script still executes. Only when the item is completely finished does the runtime move the run's cursor to the recorded target instead of stepping to the next item in order. The target is a single slot, not a queue, so the **last call wins** — a call in the test script overwrites one made in the pre-request script of the same item. Because it is a seek rather than a step, the target may sit earlier in the order, which is how paging and polling loops are built inside one collection.
code
javascript · 2 linesconst more = pm.response.json().nextPage != null;
pm.execution.setNextRequest(more ? "Fetch page" : "Summarise results");go deeper
Be ready to recall the plain fact: a Postman script can name the request the run should go to next, and the current request still completes first. Know the call lives on pm.execution and takes a request name.
Explain the mechanism: the call records a target and returns, the runtime seeks the cursor after the item finishes, and the last call during that item overwrites any earlier one. Say why that makes it a seek rather than a jump.
Show the operational consequence: a route decided in one place and silently overwritten in another, and loops that nothing bounds but your own condition. Describe how you would keep a collection's routing readable and its loops finite.
Own the tradeoff of encoding control flow inside a collection at all. Argue when branching belongs in the artefact and when it belongs in the thing driving the artefact, and what that choice costs in reviewability.
## The vocabulary this turns on A **collection run** in Postman executes a flat, ordered sequence of **items**. An item is one request together with the scripts attached to it, and the order is simply the position of the entries in the collection file's `item` array. As the run proceeds, the runtime holds a **cursor**: the position it is currently executing. `pm.execution.setNextRequest` is a member of the **sandbox's** `pm` surface — the object handed to scripts — and it is the supported way for a script to move that cursor somewhere other than the next position. ## The call records a target; it does not transfer control The most common misreading is that this behaves like a `goto`. It does not. Calling it: - returns immediately, so every statement after it in the same script still executes; - does not cancel the send — call it in the pre-request script and the request still goes out; - does not cancel response handling — the item's test script still runs; - takes effect only once the current item is completely finished, at which point the runtime performs a **seek**: it repositions the cursor at the recorded target instead of advancing by one. | What candidates expect | What the runtime does | |---|---| | Control leaves the script at the call | The call returns; the rest of the script runs | | The current request is abandoned | The current request completes normally | | The named request runs at once | It runs after the current item finishes | | Each call fires its own jump | Calls overwrite one recorded target | The deferral is not an accident of implementation you should work around. It is what makes the mechanism composable: a script can decide the route from evidence it only has *after* the response has arrived, without the run having to unwind anything it has already started. ## Last call wins The target is one slot, not a queue. If a script records `"Cleanup"` and a later script on the same item records `"Report"`, the run goes to `Report`. Two conflicting calls neither cancel each other nor both happen — the later one silently overwrites the earlier, across the pre-request and test scripts alike. That yields a useful pattern: 1. Record a conservative default early, before you know how the request went. 2. Inspect the response once it arrives. 3. Overwrite the target with the real route, or leave the default standing. It also yields a trap: two scripts that both want to steer the same item will not produce an error, a warning, or a merged route. One of them simply loses, and which one lost is not visible in the report. ## It is a seek, so it can go backwards Because the cursor is repositioned rather than stepped, the target may sit **before** the current item, and the stretch between the two runs again. This is how paging and polling are built inside a single collection: the last item of the loop records the first item of the loop for as long as the response says there is more to fetch, and stops recording one when there isn't. Nothing bounds that loop except your own condition — the runtime is not counting laps on your behalf, so a condition that never becomes false is an unbounded run. ## What it does not do - It does not skip or abort the current request; that is a different call entirely. - It does not start a second, nested run — the named item is visited by the same run, in place. - It does not edit the collection. The stored order is untouched; the deviation lasts only for this run. - It does not queue several hops. One recorded target, consumed once, when the item ends. ## Talking about it in an interview Three sentences carry the whole answer, and an interviewer is listening for all three: - **It is deferred.** The seek happens after the current item finishes, not at the call. - **It is last-call-wins.** One slot, overwritten, across both of an item's scripts. - **It is a seek, not a step.** The target may be behind you, which makes loops possible and unbounded loops your own responsibility. A candidate who says only "it jumps to the named request" has described the intent and missed every mechanism that makes the feature behave surprisingly in a real collection.
- If you call it in the pre-request script, is the request still sent?Yes. The call records a target and returns; it has no effect on the current item at all. The request goes out, the response arrives, the test script runs, and only then does the runtime seek the cursor to the recorded target. Dropping the current request is a separate call, not this one.
- How would you build a bounded polling loop with it?Record the loop's first item as the target only while a condition holds, and carry the attempt count in a variable the script increments each lap. When the count passes your ceiling, stop recording a target — or record the item that reports the timeout — so the run leaves the loop. The runtime imposes no lap limit of its own.
- Two scripts on the same item both call it. How do you find out which one won?You cannot from the report — there is no warning and no merged route, the later call simply overwrites the earlier. You establish it by reading the scripts and reasoning about execution order, or by having each candidate branch record a distinct marker value you can inspect afterwards.
It is a forwarding address left on the desk, not a door you walk through: you finish the day's work first, and only the last address written down is read.
saying these in an interview costs you the question
- Says it jumps immediately, abandoning the current request
- Thinks the rest of the script after the call is skipped
- Believes several calls queue up multiple hops
- Assumes the target must come after the current item
- Confuses it with dropping or skipping the current request
- Expects an error when two scripts both set a target