When one Postman variable store holds two entries with the same key, which one does a script read?
answer
- A store is an ordered list
- Uniqueness is never enforced on keys
- The scan runs from the end backwards
- Later definitions shadow earlier ones
basics
~20 sThe last enabled entry wins. Postman's SDK resolves a duplicated key by scanning the stored list in reverse for the first entry that is not disabled, so later definitions shadow earlier ones within the same store.
solid answer
~40 sA Postman variable store is a list, not a map, so nothing stops two entries carrying the same key. Resolution is deterministic anyway: the SDK's `oneNormalizedVariable` returns the indexed entry when it is enabled, and otherwise **traverses the members list in reverse** looking for the last entry with that key that is not disabled, then re-points the index at it. So within one store the **last enabled** duplicate wins, and if every duplicate is disabled the key resolves to nothing at all. This is a *within-store* rule and it runs before the cross-store layer walk: each store first settles which of its own entries is in force, and only that entry takes part in the chain that compares stores.
code
json · 6 lines{
"values": [
{ "key": "host", "value": "first.example" },
{ "key": "host", "value": "second.example" }
]
}go deeper
Know that a store keeps an ordered list and does not enforce unique keys, so the same name can appear twice. The later enabled entry is the one a script actually reads.
Explain the mechanism: a reverse traversal of the entry list that skips disabled entries and stops at the first usable hit, which is the last enabled entry in file order.
Show the diagnosis. When an edit to a variable appears to have no effect, check for a duplicate key further down the same store before suspecting caching or the wrong store entirely.
Own the prevention. Decide how shared stores are merged and reviewed, because any process that concatenates entry lists instead of reconciling keys manufactures duplicates that nothing will flag.
## A store is a list, not a map A Postman variable store — an environment, a globals set, the collection's own variables — is held as an ordered **list of entries**, each carrying a key among its fields. Nothing in that structure enforces key uniqueness, so a store perfectly legitimately holds two entries named `host`. Merged files, copied rows and hand edits all produce this, and it is not rejected at load time. The question is therefore not *whether* duplicates can exist but *which one answers*. ## The resolution rule The SDK settles it inside `oneNormalizedVariable`: 1. The list keeps an index from key to entry. If the indexed entry is present and **not disabled**, it is returned straight away. 2. Otherwise the members list is traversed **backwards, from the end towards the start**, looking for an entry whose key matches and which is not disabled. 3. The first such entry found in that reverse scan — that is, the **last enabled** entry in list order — becomes the answer, and the index is re-pointed at it. 4. If the reverse scan finds nothing usable, the key resolves to nothing and the read yields `undefined`. The direction of that scan is the entire fact. Because it runs from the end, **later definitions shadow earlier ones**, which is the opposite of the cross-store rule where the *first* layer to answer wins. ## Two rules, two scopes — do not mix them up | Question | Scope of the rule | Winner | |---|---|---| | Two entries with one key inside a single store | within a store | the **last** enabled entry | | One key defined across several stores | across the layer chain | the **first** layer that answers | They compose in that order: each store first decides which of its own entries is in force, and only that surviving entry takes part in the comparison between stores. A store whose duplicates are all disabled contributes nothing to the chain and is simply passed over, exactly as if the key were absent from it. ## Why this matters in a real store - **A duplicate is invisible at a glance.** Two rows named `host` look like one row and a typo, and the one that answers is not the one nearer the top. - **Editing the wrong twin does nothing.** Changing the earlier duplicate leaves reads unchanged, because the later enabled entry is still the one being resolved. - **Disabling the winner promotes the loser.** Switching off the last enabled duplicate does not clear the key — the reverse scan simply settles on the previous enabled entry instead. - **All-disabled duplicates resolve to nothing.** The key still appears in the file, but no read will ever produce a value from that store. - **Merging two stores is how duplicates appear.** Any process that concatenates entry lists rather than reconciling keys will create them silently. ## Attribution - The **entry list with its key and `disabled` fields** belongs to the collection format. - `oneNormalizedVariable`, the reverse scan and the index it maintains belong to the **SDK**. - `pm.environment`, `pm.globals` and `pm.collectionVariables`, through which a script observes the outcome, are the **sandbox's** surface. ## Answering it well State the rule — last enabled wins within a store — and immediately name the mechanism that produces it: a reverse traversal of the entry list that skips disabled entries. Then draw the contrast that shows you understand both directions: *within* a store the last enabled entry wins, *across* stores the first layer that answers wins. Close with the practical consequence — a duplicate makes editing feel unresponsive, because the row you changed may not be the row that resolves.
- How does the within-store rule combine with the order in which stores are searched?They run in sequence. Each store first resolves its own duplicates down to a single in-force entry, and only that entry joins the cross-store walk. A store whose duplicates are all disabled contributes nothing and is passed over, so the next store in the chain answers instead.
- What happens when the last enabled duplicate is switched off?The reverse scan continues past it and settles on the previous enabled entry with the same key, so the key keeps resolving — just to an older value. Only when every duplicate is disabled does the store stop answering for that key altogether.
saying these in an interview costs you the question
- Says the first entry in the list always wins
- Assumes duplicate keys are rejected when the store loads
- Thinks a duplicated key resolves to nothing at all
- Believes a disabled duplicate still blocks the earlier one
- Confuses last-wins within a store with first-wins across stores