skip to content

In Postman variable resolution, how does a disabled entry affect which store's value a script reads?

level: middleimportance: must knowfreq 46%

answer

  1. Disabled is not the same as empty
  2. The check runs at every step
  3. Skipping it hands the name downward
  4. Absent, so the next layer answers

basics

~20 s

A disabled entry counts as absent. Postman's VariableScope requires a match to be present and not disabled, so the search steps over it and continues into the next layer, letting a farther store supply the value.

solid answer

~40 s

The SDK's `VariableScope.get` never treats a disabled entry as an answer. It first looks in the scope's own `values`; if that entry is missing **or** its `disabled` flag is `true`, it walks `_layers` and breaks only on an entry that exists and is not disabled. The final return re-checks the same condition, so if every candidate along the chain is disabled the call yields `undefined`. `has` applies the identical test and reports `false`. The practical effect is that switching an entry off does not merely blank the value — it hands resolution to the next layer down, so an environment entry that gets disabled can silently expose a collection variable or a global of the same name.

code

json · 6 lines
json
{
  "values": [
    { "key": "host", "value": "staging.example", "disabled": true },
    { "key": "region", "value": "north" }
  ]
}

go deeper

for a junior

Remember the headline: a switched-off entry behaves as if it were not there. Reading it will not give you its value, and the name may still resolve from somewhere else entirely.

for a middle

Explain where the check sits — on the local values, inside the layer loop, and again on the returned candidate — and why that makes the outcome a handover to the next layer rather than a failed read.

for a senior

Demonstrate the diagnosis. When a run uses a value nobody recognises, show how you establish which layer answered and whether a nearer entry was skipped because it was disabled.

for a principal

Own the hygiene rule. Decide whether switched-off entries may linger in shared stores at all, since a dormant duplicate quietly changes which layer answers the day someone toggles the one above it.

## The rule in one line In Postman's SDK, **a disabled entry is not a match**. Every step of the lookup tests the entry's `disabled` flag, and an entry carrying `disabled: true` is skipped as though the key were not defined there at all. That is a different outcome from "the value is empty" and a different outcome from "the lookup fails" — it means resolution **continues** to the next place it would have looked. ## Where the check is applied `VariableScope.get(key)` applies the same predicate three times over: 1. **The scope's own `values`.** The entry is accepted only if it is present and not disabled; if it is missing or disabled, the layer walk begins. 2. **Each layer in turn.** The loop over `_layers` breaks on the first entry that exists and is not disabled. A disabled entry in a layer does not stop the loop. 3. **The return itself.** The value is produced only if the surviving candidate exists and is not disabled; otherwise the call returns `undefined`. `has(key)` is built the same way and returns a boolean under exactly the same condition, so `has` and `get` can never disagree about whether a name is in force. ## What a disabled entry does, versus what people assume | Situation | Common assumption | What actually happens | |---|---|---| | Nearest entry disabled, a farther layer has the key | The read yields nothing | The farther layer's value is returned | | Nearest entry disabled, no other layer has the key | An error is raised | `get` returns `undefined` | | Every entry for the key disabled | `has` returns `true`, the entries exist | `has` returns `false` | | Entry disabled | The value is hidden but still readable | It is skipped by the lookup entirely | ## Why this bites in practice Because resolution continues rather than stopping, **disabling an entry can change which store answers** instead of simply removing the answer. Two failure shapes come from this: - **The reappearing value.** An environment entry for `host` is switched off with the intent of clearing it. A collection variable or a global of the same name is still enabled further down the chain, so requests keep resolving `host` — just to a different value than anyone expected. Nothing reports this; the walk simply found its match one layer later. - **The silent unresolved name.** The nearest entry is disabled and nothing farther down defines the name, so the read yields `undefined`. There is no exception and no warning at the moment of the read. Both are the same mechanism seen from opposite ends, and both are why "is it disabled?" is the second question to ask when a Postman value is wrong — after "which layer is answering?" ## Attribution Keep the ownership straight when you explain this: - `disabled` is a **collection-format** field carried on a stored entry. - `VariableScope`, its `get`, its `has` and the `_layers` array it walks are the **SDK's**. - `pm.variables` and the per-store accessors that expose all of this to a script are the **sandbox's** surface. ## How to answer it Say that a disabled entry is treated as absent rather than as an empty value, that the check is applied at every step of the walk including the final return, and that the consequence is a handover: the next layer down gets the chance to answer. Finish with the diagnostic point — when a value is unexpectedly wrong rather than unexpectedly missing, a disabled entry that let a lower layer through is a prime suspect.

  • If the nearest entry is disabled and nothing farther down defines the name, what comes back?
    `undefined`. The walk steps over the disabled entry, exhausts the remaining layers without a usable match, and the final check refuses the disabled candidate as well. `has` reports `false` for the same name, so both calls agree that nothing is in force.
  • How would you confirm that a disabled entry is why a request used the wrong value?
    Compare what the combined lookup reports against each single store. If `pm.variables.get` returns a value that the store you expected to own the name does not carry, some nearer entry was skipped and a farther layer answered — a disabled entry in the nearer store is the usual cause.

saying these in an interview costs you the question

  • Says a disabled entry resolves to an empty string
  • Thinks disabling a name makes every read return undefined
  • Believes disabled only hides the row in the app
  • Assumes the walk stops at a disabled match
  • Claims has returns true because the entry still exists