In JMeter, why can a sampler not use a value that its own Post-Processor extracts?

## The mechanism A Post-Processor is, by definition, an element that runs **after** its sampler. The manual's execution order puts the Sampler at step 3 and Post-Processors at step 4, and `JMeterThread.executeSamplePackage(...)` calls `runPostProcessors(...)` only inside the `if (result != null)` block that follows `doSampling(...)`. By the time a Post-Processor runs, the sampler it is attached to has already: 1. had the config elements merged into it, 2. had its Pre-Processors run, 3. served its timers, 4. had every `${...}` reference in its URL, headers and body resolved, 5. gone out on the wire and come back. Step 4 is the one that ends the argument. The request was rendered *before* the extraction existed, so the extraction cannot possibly have contributed to it. The earliest consumer of an extracted value is the **next** sampler the thread reaches. ## The worked example ```text Thread Group HTTP Request POST /login <-- sends Authorization: Bearer ${token} JSON Extractor token <- $.access_token HTTP Request GET /orders <-- this one can use ${token} ``` The `JSON Extractor` under `/login` writes `token` from the login response. The `/login` request itself was already on the wire when that happened. `/orders`, which the thread reaches afterwards, is the first request that can carry the value. ## What the failing request actually sends &mdash; not blank This is the detail candidates most often get wrong, and it changes how you debug. A reference to a variable that has **never been set** does not render as an empty string. JMeter compiles a non-function `${token}` to a `SimpleVariable`, whose `toString()` is: ```java if (ret == null) { return "${" + name + "}"; } ``` So the header goes out carrying the literal eight characters `${token}`. In a listener or a JTL you will see the placeholder itself in the request data &mdash; which is a much louder signal than a blank field, once you know to look for it. A field is genuinely **empty** only when something has already written an empty value into the variable. The common route is that the extractor did run on an earlier sampler, failed to match, and stored its configured default; in `RegexExtractor.process()` the default is written up front, `if (!defaultValue.isEmpty() || isEmptyDefaultValue())`, before any matching is attempted. So: | What you see in the request | What it tells you | |---|---| | the literal `${token}` | nothing has ever set `token` &mdash; wrong ordering, or wrong variable name | | an empty value | something set `token` to empty &mdash; the extractor ran and did not match | | a stale, plausible value | the extractor ran on an earlier iteration and has not been refreshed | ## The other trap: User Defined Variables A tempting "fix" is to declare the variable in a User Defined Variables element so it is defined before the request. That does not work, and the component reference says why: *"all the UDV elements in a test plan &mdash; no matter where they are &mdash; are processed at the start. So you cannot reference variables which are defined as part of a test run, e.g. in a Post-Processor."* The element is evaluated once, at the beginning, and never again. ## How to confirm the ordering rather than guess - Put a **Debug Sampler** immediately after the sampler whose response defines the value; its output shows the thread's variables at that point, so you can see whether the extraction happened. - Look at the *request* pane in **View Results Tree** for the failing sampler: a literal `${token}` in the headers is proof the value did not exist yet, not proof the extractor is broken. - Remember that moving the Post-Processor higher in the tree changes nothing. Tree position orders elements only *within* a type; a Post-Processor drawn above a sampler still runs after it. ## The one-line rule Extraction is retrospective. Whatever a Post-Processor produces belongs to the requests that come after it, never to the request whose own response produced it.