A JMeter sampler has two HTTP Cookie Managers in scope after a plan merge. Which one applies?

## Why two of them ends up in a plan Nobody adds two Cookie Managers on purpose. They arrive by scope. A Test Fragment or a copied flow brings its own Cookie Manager, and it is pasted under a controller inside a Thread Group that already has one at the top. Or two plans are merged and each contributed a manager at a different depth. Both are now on the path from the sampler up to the Test Plan, so both are in scope, and the sampler has no way of telling you that. ## What the engine does with them JMeter's scoping rules state that the Header Manager, Cookie Manager and Authorization Manager are treated differently from the Configuration Defaults elements: the settings from Defaults are merged into a set of values that the sampler can see, but the settings from the Managers are **not** merged. If more than one Manager is in scope, only one Manager is used, and the manual is candid that there is currently no way to specify which. The HTTP sampler's own behaviour matches. As it is handed each config element in scope it sets the Cookie Manager, and when one is already present it logs a warning of the form `Existing CookieManager <name> superseded by <name>` at WARN level before replacing it. That log line is the single best diagnostic here: it names both elements, so you can find them in the tree without guessing. ## Why it hurts more than "one of them is ignored" If the two managers were interchangeable the loss would be cosmetic. They are not. Each Cookie Manager owns its own cookie storage area, and the component reference warns explicitly that a cookie stored in one cookie manager is not available to any other manager. So the sequence that breaks is: 1. The login sampler runs in a branch where manager A is the one used, and the session cookie is stored in A. 2. A later sampler sits where manager B is the one used. 3. B has never seen that cookie, so the request goes out unauthenticated. 4. The server answers with a login page rather than the resource, so the damage surfaces at a sampler far from the one that caused it. The result reads as an intermittent authentication defect in the system under test, when the cause is two elements sharing one sampler's scope. ## How to find it - **Grep the log.** Search `jmeter.log` for `superseded by`. Each hit names the pair of elements involved. - **Trace the path.** For a failing sampler, walk from it up to the Test Plan and count Cookie Managers. Anything above one is the bug. - **Search the .jmx.** Count `CookieManager` elements in the file, then look at which `hashTree` each sits in. - **Look at the response, not the status code.** The failure mode returns a healthy status with the wrong body, so the sampler shows green unless an assertion checks content. ## How to fix it The rule to converge on is one Cookie Manager per Thread Group, attached directly under the Thread Group, and none anywhere else on that path. If two different populations genuinely need separate cookie jars, give them separate Thread Groups rather than nested managers — that keeps each sampler in the scope of exactly one manager and makes the boundary visible in the tree. When a reusable fragment carries its own manager, strip it and rely on the group's. The same discipline applies to the HTTP Authorization Manager, whose page carries the identical note that with more than one in scope there is no way to specify which is used. ## The contrast worth holding in your head | Element | Two in one sampler's scope | | --- | --- | | HTTP Request Defaults | values are merged into one set the sampler can see | | HTTP Header Manager | entries are merged into one header list | | HTTP Cookie Manager | one is used; which one is unspecified | | HTTP Authorization Manager | one is used; which one is unspecified | Two of those four compose and two do not, and the two that do not are precisely the ones carrying per-thread session state. That is why the failure is silent: nothing is dropped loudly, a whole cookie jar is simply not the one in play.