A JMeter checkout run passed every sample although each request carried a literal ${sessionId}. What happened?

This is the JMeter failure that produces the most confident wrong report: a full run, thousands of samples, zero errors, and not one request that the application could actually serve. ## Unset does not mean empty When JMeter compiles a field containing `${sessionId}`, a reference that is not a function call becomes a `SimpleVariable`. Its `toString()` is short enough to quote in full in an interview: ```java String ret = null; JMeterVariables vars = getVariables(); if (vars != null) { ret = vars.get(name); } if (ret == null) { return "${" + name + "}"; } return ret; ``` A missing variable therefore renders as its own reference text. There is no warning, no error-level log line, and nothing that changes the sample's verdict — the substitution simply produces a different string from the one you intended. That is worth contrasting with a **malformed function call**, which behaves in exactly the opposite way: a wrong parameter count aborts the test-tree compile with `Error occurred compiling the tree:` before any thread starts, so you get no results file at all. Functions fail loudly; plain variable references fail silently. ## Why the server keeps the run green The requests that go out are syntactically valid. A header reading `Authorization: Bearer ${sessionId}` is a well-formed header with an odd value; a URL containing `/orders/${sessionId}` is a well-formed URL. Real applications answer these politely: - an API returns `200` with `{"error":"invalid session"}` - a web front end returns `200` with the login page - an edge tier returns `302` to `/login` - a strict validator returns `400`, and this is the only one of the four JMeter fails on its own Three of those four are inside `200–399`, so the samples pass. This is the same run that **reported zero errors while serving error pages** — the elapsed times JMeter recorded are the times of rejections, and the sample counts in its report are counts of rejections. ## How the variable came to be unset Two causes cover nearly all cases, and both are silent by design: 1. **The extractor missed.** The reply that should have carried the session id was itself an error page, so nothing matched, and with a blank Default Value and the empty-default box unticked the extractor wrote nothing at all. 2. **The names do not agree.** The reference name on the extractor and the `${...}` in the sampler differ by a letter or by case. Nothing in JMeter cross-checks them. Both leave the reference unresolved and both leave the verdict untouched. ## Confirming it in five minutes The diagnosis is quick once you know what you are looking at: - Open a **View Results Tree** and select a passing sample. The **Request** tab shows the request body and the headers JMeter added, with `${sessionId}` still sitting there in plain sight. The green icon beside it is telling you only that the reply's status was in range. - Put a **Debug Sampler** after the extractor with *JMeter variables* ticked. Its response data lists the thread's variables; `sessionId` is either missing from the list or holding an extractor default. - Read the **Response data** tab of the sample that was supposed to supply the value. That is usually where the real story is: it was an error page all along. ## The fix, and the guard Correct the extraction, then make the same mistake impossible to ship unnoticed. Give the extractor a distinctive `Default Value` such as `NOT_FOUND`, and attach a Response Assertion to the sampler that consumes it — either matching something only a genuine reply contains, or matching the marker so the plan fails loudly when the extraction missed. A plan that sends a value it did not capture should be a red sample, and the only way to get that in JMeter is to say so with an assertion.