skip to content

In postman-runtime, what happens when a run supplies both cookieJar and perPartitionCookieJar?

level: seniorimportance: nice to knowfreq 20%

answer

  1. Two options, one store, one conflict
  2. The explicit object beats the strategy
  3. The loser is discarded, not rejected
  4. A warning is the only signal

basics

~20 s

The explicit jar wins. An explicitly supplied requester.cookieJar always beats requester.perPartitionCookieJar, which is then ignored and warned about, so the run uses the one jar you handed it instead of keeping a jar per partition.

solid answer

~40 s

The two options describe the same store in incompatible ways: `requester.cookieJar` says "use this jar object", `requester.perPartitionCookieJar` says "keep a jar per partition". Supplying both is a conflict, not a combination, and the explicit jar always wins — the per-partition option is ignored and the runtime emits a warning. The practical danger is that nothing fails: requests still send cookies and assertions still pass, so a harness that adds `cookieJar` to seed or inspect state can silently switch off partitioning that something else relied on. The consequence shows up later as shared state where isolation was expected, with a discarded warning as the only evidence. Decide which behaviour you actually want and set exactly one of the two.

code

javascript · 6 lines
javascript
const runOptions = {
    requester: {
        cookieJar: jar,
        perPartitionCookieJar: true
    }
};

go deeper

for a junior

Remember the direction of the rule: when a run is handed an actual jar object, that jar is what gets used, and the option asking for a jar per partition has no effect at all.

for a middle

Explain that the two options are mutually exclusive descriptions of the same store, that the explicit one wins, and that the discarded one produces a warning rather than an error.

for a senior

Show that you would catch this in practice: read a run's warnings, and treat adding an explicit jar to a shared harness as a behaviour change for anything that was depending on partitioned stores.

for a principal

Own how configuration conflicts are surfaced in your tooling. A setting that is silently discarded lets behaviour and configuration diverge, and deciding that such cases must fail loudly is a standard worth setting.

## Two options that describe the same store Runtime options carry two settings about the cookie store. `requester.cookieJar` hands the run **a specific jar object** to use — the way you seed a run with existing state or keep a jar you can inspect afterwards. `requester.perPartitionCookieJar` asks instead for the store to be kept **per partition** rather than as one jar shared across everything the run does. They describe the same thing in two incompatible ways: one says "use this jar", the other says "keep several". Supplying both is therefore not a combination but a conflict. ## The precedence rule **An explicit `requester.cookieJar` always wins.** When both are supplied, `perPartitionCookieJar` is ignored and the runtime emits a warning. The run then behaves exactly as if you had asked only for the explicit jar. | Options given | What the run uses | |---|---| | `cookieJar` only | that jar, shared across the run | | `perPartitionCookieJar` only | a jar per partition | | both | the explicit `cookieJar`; the per-partition option is ignored, with a warning | | neither | the runtime's own default store for the run | ## Why this matters in practice The failure mode is silent in every way that counts, because the run still succeeds: - A harness adds `cookieJar` for one reason — seeding a session, inspecting the store at the end — and unknowingly turns off partitioning that something else was relying on. - Nothing fails. Requests still send cookies, assertions still pass, and the only signal is a warning in the run's output that nobody is reading. - The consequence appears later as **shared state where isolation was expected**: entries written under one partition are visible everywhere, because there is now only the one jar you supplied. ## How to keep it straight 1. **Decide which one you actually want**, and set exactly that one. If the store must be partitioned, do not also hand in a jar. 2. **If you need both an inspectable jar and isolation**, you have to get isolation some other way — the options themselves do not compose. 3. **Read the warnings from a run.** This is one of the cases where the only evidence that a setting was discarded is a line the runtime logged and no assertion covers. 4. **Write down which option a shared harness sets.** The next person to add `cookieJar` for a good local reason will otherwise change behaviour for everyone. ## The general shape of the rule The pattern is worth recognising beyond this one pair: when a configuration surface offers both *"here is the object to use"* and *"here is how to construct the objects"*, the explicit object almost always wins, because there is nothing sensible to do with a construction strategy once an instance has been supplied. What distinguishes this case is only that the loser is discarded **quietly** — a warning, not an error — so the run's behaviour and the run's configuration can silently disagree for a long time.

  • Why is this precedence rule easy to miss in a real harness?
    Because nothing fails. The run completes, cookies are sent, and assertions pass; the only evidence that a setting was discarded is a warning in the run's output that no assertion covers. The behaviour and the configuration disagree silently, often for months.
  • If you need both an inspectable jar and per-partition isolation, what do you do?
    You cannot get both from these options — supplying the jar discards the other setting. Either give up the explicit jar and let the runtime keep partitioned stores, or keep the jar and obtain isolation another way, such as running the work as separate runs with their own stores.

saying these in an interview costs you the question

  • Thinks the two options combine into partitioned copies
  • Expects a conflicting pair to raise an error
  • Assumes the later assignment simply wins
  • Adds an explicit jar without checking what relied on partitioning
  • Ignores warnings emitted by a run