skip to content

Why is what you read in Postman's console a rendering of your value rather than the value itself?

level: seniorimportance: should knowfreq 34%

answer

  1. The object never leaves your script
  2. Something is copied at call time
  3. Serialised args cross the sandbox boundary
  4. A snapshot rendering, not a live reference

basics

~20 s

Console arguments are serialised at the moment of the call and shipped out of the sandbox. The host renders that serialisation, so you read a snapshot of what crossed the boundary, never the live object itself.

solid answer

~40 s

A Postman script's `console` never hands anything to a host directly. `PostmanConsole` **dispatches an `execution.console` event** carrying the cursor, the level and the **serialised arguments** — your values converted into something that can cross the sandbox boundary. That conversion happens as part of the call, so what a reader eventually sees is built from a copy taken at that instant. Three things follow: mutating the object afterwards cannot change an already-dispatched message; anything the serialisation could not carry is simply absent from the rendering; and the script can never read the message back, because the dispatch is one-way. Debug accordingly — log the specific fields you are reasoning about, log before and after a mutation you care about, and do not treat a surprising rendering as proof of a bug.

code

javascript · 4 lines
javascript
const payload = { id: 1 };
console.log(payload);
payload.id = 2;
console.log(payload);

go deeper

for a junior

Remember that the console shows a copy taken when you called it. If you change an object afterwards, log it again rather than expecting the earlier line to update.

for a middle

Explain that the arguments are serialised and dispatched with the event, so the host renders a snapshot; the object itself never crosses the sandbox boundary at all.

for a senior

Show the debugging judgment: log the specific fields under investigation, bracket a mutation with two calls, and check the boundary before blaming the tool for an odd rendering.

for a principal

Frame it as the price of isolation: a sandbox that let a host hold references would not be a sandbox, so snapshot rendering is a deliberate consequence rather than a defect to route around.

## Serialisation happens at the moment of the call When a Postman script calls a member of the sandbox `console`, the arguments do not stay in the script's world. `PostmanConsole` **dispatches an `execution.console` event** carrying the execution cursor, the level, and the **serialised arguments** — your values converted into a form that can cross the sandbox boundary. That conversion happens synchronously, as part of the call. Everything a reader later sees is produced from that serialised copy. The host renders it; the host never holds your object. So the console shows **a rendering of what your value looked like when the call was made**, and not the value. ## Live value versus rendered message | | the value in your script | what the console shows | |---|---|---| | identity | the object itself | a rendering of a serialised copy | | when it was fixed | changes as the script runs | fixed at the moment of the call | | what it contains | everything the object has | whatever survived serialisation | | who can change it | your script | nobody; the message has left | | readable back by the script | yes | no | ## Three consequences worth internalising 1. **Later mutation is invisible.** Log an object, then change a field on it, and the already dispatched message still describes the earlier state. Two calls around a mutation give you two snapshots; one call before it gives you one, no matter what happens afterwards. 2. **Whatever does not survive serialisation is simply not there.** The message can only carry what the conversion could express. If you are staring at a rendering that looks emptier than the value you thought you had, the boundary — not the host's display — is usually the reason. 3. **The console is not a value store.** There is no way to read a message back into the script. Anything the run itself needs to act on later has to live somewhere the run reads back; where that is belongs to a different subject entirely. ## Debugging habits that survive the boundary - **Log the specific fields you are reasoning about**, not the whole object, when you care about exact values. A short, explicit message is unambiguous in a way a rendered structure is not. - **Log before and after a mutation** if the change is what you are investigating; one message cannot show you a transition. - **Convert deliberately when the shape matters.** If you want to be certain what crossed the boundary, decide the representation yourself rather than leaving it to the serialiser and then arguing with the result. - **Do not diff a rendering against your mental model of the object.** You are comparing two different things, and the discrepancy is frequently the serialisation rather than a bug. - **Never log a credential.** The serialised value leaves the sandbox and lands wherever the host puts it, which is not a decision your script gets to make. ## Why this design, and not a live view A live view would require the host to hold a reference into the sandbox's memory, which is exactly what a sandbox exists to prevent. Isolation is the point: the script gets an execution context of its own, and the only thing that crosses the boundary is a message. A snapshot rendering is the honest consequence of that isolation, not a limitation somebody forgot to fix. It also explains the asymmetry people find surprising. Inside the script, your object is live, mutable and inspectable. Outside, there is a message that was true at one instant, addressed to whoever is listening, with no way back. Both halves are consistent; they are just not the same thing, and the console pane is showing you the second one. ## Common misreadings - Believing the console holds a live reference and re-renders as an object changes. - Concluding a value is wrong because its rendering is unfamiliar, rather than checking what serialisation could carry. - Trying to recover a logged value later in the run instead of keeping it where the run can read it. - Assuming a difference between the rendering and the script's view proves a bug in the tool.

  • A field you know exists is missing from what the console shows. Where do you look first?
    At the boundary, not the display. The message can only carry what serialisation could express, so a value that does not survive the conversion is absent from the rendering while still being perfectly present in the script. Log that field explicitly, or convert to a representation you have chosen yourself, before concluding anything about the object.
  • Can a script retrieve a value it logged earlier in the run?
    No. The console dispatches outward and nothing reads back into the sandbox, so a logged value is gone as far as the script is concerned. Anything the run must act on later has to be kept somewhere the run reads back; the console is a diagnostic addressed to a human, not a store.

It is a photograph of the value, not a window onto it: the picture is fixed the moment you take it, and it only captures what the camera could see.

saying these in an interview costs you the question

  • Believes the console holds a live reference to the object
  • Expects a later mutation to change an already-logged message
  • Tries to read a logged value back inside the script
  • Calls a rendering difference a bug in the tool
  • Logs whole objects when exact field values matter