In REST Assured, when will a SessionFilter or CookieFilter refuse to apply the session it captured?

## Three writers, one cookie slot By the time a REST Assured request goes out, up to three different mechanisms may want to put a session cookie on it, and they run at different moments: 1. **The DSL**, as you build the spec — `given().sessionId(...)` or `given().cookie(...)`. 2. **A filter**, when the filter chain runs — `SessionFilter` or `CookieFilter`. 3. **The configuration**, inside the internal send step — `SessionConfig.sessionIdValue`, which is where an assignment to `RestAssured.sessionId` is folded when `given()` is called. Every one of them after the first checks whether the slot is taken and, if it is, does nothing. The result is a **first-writer-wins** rule that is not written down anywhere obvious in the DSL. ## What each one checks - `SessionFilter` applies its stored id only when `requestSpec.getCookies().hasCookieWithName(config.getSessionConfig().sessionIdName())` is false. It also stores the response's session id afterwards regardless, so a request that ignored the filter can still refresh it. - `CookieFilter` walks its cookie store and, for each stored cookie that matches the request URI, applies it only when the request has no cookie of that name. Constructing it as `new CookieFilter(true)` — the `allowMultipleCookiesWithTheSameName` flag — turns that check off and lets a stored cookie ride alongside one you set explicitly. - The `SessionConfig` value is applied in the send step, again only when no cookie of that name is already on the spec. - `given().sessionId(name, value)` is the one exception: it evicts any same-named cookie and replaces it. It is the only mechanism here that overwrites. ## The precedence table | set by | runs | overwrites? | effective rank | | --- | --- | --- | --- | | `given().sessionId(...)` / `given().cookie(...)` | while the spec is built | `sessionId` replaces; `cookie` appends | highest | | `SessionFilter` / `CookieFilter` | in the filter chain | no — stands down | middle | | `SessionConfig.sessionIdValue` / `RestAssured.sessionId` | in the send step | no — stands down | lowest | Note that this is the opposite of the intuition "the thing that runs last wins". Running last is exactly why the config value has the least authority: by then, anybody else has already claimed the slot. ## Where the rule helps you The obvious win is negative testing. A beehive telemetry suite that carries a live session through a `SessionFilter` can still assert the unauthenticated path without unwiring anything: ```java given() .filter(apiarySession) .sessionId("expired-hive-session") .when() .get("/hives/h-42/telemetry") .then() .statusCode(401); ``` The filter holds a perfectly valid id, sees `JSESSIONID` already on the request, and yields. The same is true with `RestAssured.sessionId` set globally. Without the rule you would have to build a separate spec with no filter just to test a rejection. ## Where the rule hurts you The failure mode is the mirror image, and it is quiet. Suppose a shared `RequestSpecification` for the beehive API was built with a session id in it at some point, and later somebody adds a `SessionFilter` to refresh the session per test. Every request now carries the stale cookie from the spec, the filter stands down on every call, and the freshly captured id is never used. Nothing logs a conflict; the tests just fail against a session that expired last Tuesday. Symptoms worth recognising: - `sessionFilter.hasSessionId()` is `true` and the request still `401`s. - Logging the outgoing cookies shows a value that does not match `sessionFilter.getSessionId()`. - Removing an unrelated-looking `.cookie(...)` or `.sessionId(...)` line makes the suite pass. ## How to diagnose it in one pass 1. Print what the filter holds: `sessionFilter.getSessionId()`. 2. Print what actually went out: add `given().log().cookies()` to the failing request. 3. Compare. If they differ, something claimed the slot before the filter ran, and step three is to find which layer put it there — the inline chain, an attached spec, or a globally configured session id. ## When you genuinely want both `new CookieFilter(true)` is the escape hatch when the server legitimately expects two cookies of the same name for different scopes and you want the stored one sent alongside your explicit one. Reach for it deliberately and rarely; the default of `false` exists because sending two same-named cookies is much more often a bug than a design. There is no equivalent flag on `SessionFilter` — it carries exactly one id and always yields. If you need a request to use a captured session even though the spec already names that cookie, the fix is to stop putting the cookie on the spec, not to fight the filter. ## The short version Nothing in REST Assured's session machinery ever overwrites a cookie somebody else already put on the request. That makes explicit values reliable and makes stale ones invisible, and both halves of that trade show up in real suites.