After a Postman request's script finishes, how do its variable writes reach the rest of the run?

## Scripts work on copies The first thing to get straight is that a Postman script is not editing the run. It executes in a sandbox that has been handed the run's variable scopes, and what it manipulates there are those handed-over copies. If the story stopped at that, nothing a script did would ever matter to any later request. So there is a second half: a **carry-back**, performed by the runtime once the script execution completes. The carry-back is not a wholesale copy of the sandbox's state over the run's. It is a replay of recorded changes. ## Mutations, then a replay Each scope in the sandbox records what was done to it. A `set` is recorded as a mutation; so is an `unset`. The result is a **`MutationTracker` diff** — an ordered account of what changed on that scope during this execution, rather than a picture of what the scope looked like at the end. When the script finishes, the runtime asks the sandbox for those diffs and replays them onto its own scopes. | | Whole-scope copy | Recorded diff (what actually happens) | |---|---|---| | Untouched key written by another script | lost | preserved | | A key the script removed | ambiguous | removed, because `unset` is recorded too | | Cost of the handover | the entire scope | only what changed | ## Only the tracked scopes are replayed The runtime does not collect from everything the sandbox exposes. Its item command names the scopes it wants back: - `globals` - `environment` - `collectionVariables` That list is what makes chaining possible, and its length is what makes one specific mistake fatal. The sandbox also has an execution-local layer, written through `pm.variables.set`. It records mutations exactly like the others, but nobody ever asks for them, so they are discarded with the execution and no later request can see the value. ## What the diff model buys you - **Scripts do not overwrite each other's unrelated work.** One request's script writing `orderId` and another writing `customerId` both land, because each replays only its own recorded changes. - **Deletion is a first-class change.** `pm.environment.unset('orderId')` is not the absence of a write; it is a recorded mutation, so cleaning up a chained value at the end of a flow actually reaches the run. - **Order within one script is preserved.** Two writes to the same key end at the later value, because the mutations replay in the order they were recorded. - **Nothing is visible early.** A write is not in the run's state at the moment `set` returns; it is in the run's state after the execution that made it completes. ## Where the writes come from in the lifecycle Both script events feed the same machinery, and the difference between them is only timing. A **pre-request** script's execution completes before the request is sent, so its writes are in the run's state in time for the request being built. A **test** script's execution completes after the response has arrived, so its writes are in place for whatever runs next. The mechanism is identical; what differs is which side of the send the replay lands on. One consequence is worth remembering when diagnosing. If a request fails at the transport level, its test script does not run, so nothing is collected from it. A chain that depends on that script's write is broken not because the carry-back failed but because there was never anything to carry. ## The mental model to carry into an interview Say it in one sentence and you will be right about almost every follow-up: **a script proposes changes, the runtime applies them, and it only applies changes to the scopes it declared it wanted.** From that single sentence you can derive why `pm.variables.set` cannot chain, why an untouched key survives another script's writes, why an `unset` is as durable as a `set`, and why a value appears to exist inside the script that wrote it long before it exists anywhere else.