Does pm.environment.set during a Postman run change the environment file the run was given?
answer
- The file is an input, not a log
- Read once, then held in memory
- Writes land on the scope, not the disk
- Tracked mutations carry through the run only
- Getting the end state is an explicit step
basics
~20 sNo. The run reads the environment file once into a variable scope, and script writes are tracked mutations against that in-memory scope. The file on disk is never rewritten; capturing the end state is a separate, explicit step.
solid answer
~50 sNo — the file is an **input**, not a log. A run loads the environment file's `values` entries once into a `VariableScope`, and every `pm.environment.set` or `unset` is recorded as a tracked mutation against that in-memory scope, which is how the change reaches the rest of the run. Nothing in that path writes the file: it is byte-identical before and after. Two consequences matter in practice. A committed environment file tells you where a run *began*, never where it ended. And a run may not depend on a value left over from an earlier run — anything a request needs must be in the file it was pointed at or produced by an earlier script in the same run. If you want the end-state values as a file, the run has to be asked for them.
go deeper
Know that a run loads the environment file at the start and does not write it back. Values a script sets exist for that run only.
Explain the two things involved: the file on disk and the VariableScope built from it. Script writes are tracked mutations against the scope, not edits to the file.
Demonstrate the diagnosis: a collection that only passes locally is usually leaning on values a clean run will not have, so treat a clean run from committed files as the only real green.
Own the standard that a run must produce everything it needs from its inputs, and that hand-edited local values are a machine-specific dependency the team cannot see.
## The file is an input, not a log A Postman run is handed an environment file and reads it **once**. What the run works with from then on is a `VariableScope` — the collection SDK's in-memory object built from the file's `values` array. Every `pm.environment.get` answers from that scope, and every `pm.environment.set` writes into it. The file on disk is not part of that loop. The run does not open it for writing, does not append to it, and does not rewrite it when the run ends. **A value written by a script exists in the run and stops existing when the run does**, unless something explicitly asks for the end state to be written out as a file. ## What a script write actually touches The mechanism is worth stating precisely, because the vocabulary is what interviewers listen for: 1. The run builds a `VariableScope` from the environment file's entries. 2. A script's `pm.environment.set` is recorded as a **tracked mutation** against that scope, so the change is carried through the rest of the run rather than dying with the script that made it. 3. Nothing in that path names the file. The mutation is applied to the run's state; the file is a byte-identical document before and after. | | during the run | after the run | |---|---|---| | the `VariableScope` | changes with every `set` and `unset` | discarded | | the environment file on disk | untouched | untouched | | the end-state values | live in the scope | gone unless exported | ## Three consequences that show up in real work - **An environment file in version control is a starting snapshot, not a record of what ran.** Reviewing it tells you where the run began, never where it ended. - **A run must never depend on a value "left over" from a previous run.** Anything a request needs is either in the file it was pointed at, or written by an earlier script in the same run. A collection that only passes on the second attempt is usually depending on state that a clean run will not have. - **Inspecting the end state is a deliberate step.** If you want the values a run produced, the run has to be asked to export them; nothing produces that file as a side effect. ## Why this trips people up The confusion is honest, because the *within-run* behaviour looks like persistence. A script sets `authToken`, the next four requests use it, and everything works — so the value plainly "stuck". It stuck to the scope, which lives exactly as long as the run. The moment the comparison is between two runs rather than two requests, the illusion breaks, and it breaks in the least convenient place: on a clean machine, where nobody has accumulated the values that made it work locally. ## Keeping runs honest - **Start from the file every time.** Treat "does this pass from a clean checkout, pointed at the committed environment file, with nothing carried over?" as the only meaningful green. - **Make the first request produce what later ones need.** If a token is required, fetch it inside the run rather than assuming a stored one. - **Do not hand-edit values into a file to fix a failing run** without asking why the run cannot produce them itself. That edit is invisible to everyone else and turns the file into a machine that only works on your machine. - **Diff the committed file when something suddenly passes.** A value that appeared without a commit is a value someone typed in locally. ## The short answer to give "No — the run reads the file into a scope, script writes are tracked mutations against that scope, and the file on disk is untouched. Getting the end state as a file is a separate, explicit step." Said that way, it answers the question and shows you know the difference between the artefact and the copy, which is the distinction the question is really testing.
- Why does a collection that passes on your machine sometimes fail on a clean one?Because the local run has been reading a value nobody committed. A script wrote it during some earlier session, or it was typed into a file by hand, and every run since has quietly depended on it. A clean run starts from the committed file only, so the value is simply absent and every request that needed it fails at once.
- If the file is untouched, how does a value written early in a run reach a later request?Through the run's own scope. The write is recorded against the `VariableScope` the run built from the file, so subsequent requests in the same run read the updated value. The scope lives exactly as long as the run; when the run ends it is discarded and the next run starts again from the file's contents.
saying these in an interview costs you the question
- Says the runner rewrites the environment file at the end
- Assumes values persist from one run to the next automatically
- Treats a committed environment file as a record of what ran
- Hand-edits values into the file to make a run pass
- Expects the end-state values without asking for an export