In the Postman SDK, what does VariableScope.set do when the existing entry for that key is disabled?
answer
- Writes branch on what the lookup found
- A disabled entry counts as not found
- Nothing revives or rewrites a disabled entry
- The store is left holding a duplicate
basics
~20 sIt appends a second entry rather than editing the existing one. Postman's SDK updates in place only when the entry it finds is enabled, so a disabled entry is left untouched and a new enabled entry joins it.
solid answer
~40 s`VariableScope.set` first resolves the key the same way a read does. If that lookup finds an entry which is **not** disabled, the entry is updated in place. If the lookup finds nothing usable — including the case where the only entry for that key is disabled — the scope **adds a new entry** instead. Disabled entries are never revived and never rewritten. The store therefore ends up holding two entries under one key: the original disabled one and the freshly added enabled one. Reads still behave predictably, because a duplicated key resolves to the last enabled entry, and the appended one is exactly that. The surprise is in the file rather than in the value: a write that looked like an edit was an append.
go deeper
Know that a write does not always edit the row you expect. When the existing entry is switched off, a new entry is added beside it instead of the old one changing.
Explain the branch: the write reuses the read's lookup, updates in place only on a present enabled entry, and otherwise appends — so a disabled entry behaves as if the key were undefined.
Demonstrate that you have inspected the resulting file, not just the returned value: repeated writes over disabled entries leave duplicated keys behind, which is a real review finding in a shared store.
Own the cleanup convention. Decide whether stores that scripts write to may carry disabled entries at all, since each one turns a future write into an append that nothing surfaces.
## What the write actually does `VariableScope.set(key, value)` in Postman's SDK is not a blind overwrite. It begins with the same normalised lookup a read uses, and then branches: - **The lookup found a present, non-disabled entry** — that entry is updated in place with the new value (and any type or secret option passed alongside it). - **The lookup found nothing usable** — a brand-new entry is added to the scope's list. The second branch covers two situations that feel very different but are handled identically: the key was never defined at all, and the key is defined but its only entry is **disabled**. In both cases the scope appends. A disabled entry is never updated and never re-enabled by a write. ## The state the store is left in | Before the write | Branch taken | After the write | |---|---|---| | No entry for the key | add | one new enabled entry | | One enabled entry | update | the same entry, new value | | One disabled entry | add | the disabled entry **plus** a new enabled entry | | Disabled and enabled entries | update | the enabled one changed, the disabled one untouched | The third row is the one worth remembering. The write succeeds, subsequent reads return the new value, and yet the store now carries a **duplicated key** it did not carry before. ## Why reads still come out right These two behaviours are designed to fit together: 1. A duplicated key inside one store resolves to the **last enabled** entry, found by scanning the entry list backwards. 2. The entry `set` appended is enabled and sits at the end of that list. So the value just written is exactly the one the next read finds, and the stale disabled entry earlier in the list never interferes. The mechanism is self-consistent: the append rule and the last-enabled rule are two halves of one design. ## Where it does surprise people - **The file grows.** A store that is written to repeatedly while carrying disabled entries accumulates duplicates, one per key that was disabled at write time. - **The disabled entry looks like it should have changed.** Nothing rewrites it, so it keeps its old value indefinitely and can be mistaken for the current one when the file is read by eye. - **Re-enabling the old entry does not restore the old value.** Both entries are then enabled, and the appended one is still later in the list, so it keeps winning. - **Removing the appended entry revives the disabled one only if it is enabled again.** Otherwise the key stops resolving from that store entirely. ## Attribution - `VariableScope` and its `set` are the **SDK's**. - The `disabled` flag on the stored entry is a **collection-format** field. - Scripts observe this through the **sandbox's** per-store accessors, which sit on top of the same scope objects. ## How to answer it Say that `set` updates in place only when it finds an enabled entry, and appends otherwise — with a disabled entry counting as "not found" for that decision. Then close the loop by connecting it to reads: the appended entry is enabled and last in the list, so the last-enabled rule makes the new value the one that resolves. Mentioning that the store is left holding a duplicate is what shows you have actually looked at the file afterwards rather than only at the returned value.
- After the append, which of the two entries does a later read return?The appended one. A duplicated key inside a store resolves to the last enabled entry, and the entry `set` added is enabled and sits at the end of the list. The older disabled entry keeps its stale value and never participates in resolution.
- What happens if the disabled entry is later switched back on?Both entries are then enabled and the key is genuinely duplicated. The reverse scan still stops at the last enabled entry, so the appended value keeps winning and re-enabling the original changes nothing that a read can observe.
saying these in an interview costs you the question
- Says the write updates the disabled entry in place
- Thinks the write re-enables the existing entry
- Believes writing to a disabled key is a no-op
- Assumes the store can never hold duplicate keys
- Expects the stale disabled value to win later reads