In JMeter, why does a Regular Expression Extractor that matched nothing leave its sample green?
answer
- Only one element family sets verdicts
- The extractor is a post-processor
- A field fills in when nothing matched
- It is written before the match runs
basics
~10 sAn extractor is a post-processor, not an assertion. A missed match never touches the sample's success flag; the extractor leaves the variable holding its Default Value and the thread carries on.
solid answer
~40 sJMeter's Regular Expression Extractor implements `PostProcessor`, and post-processors have no path to the sample's verdict — only an assertion lowers `SampleResult.setSuccessful`. Its `process()` method writes the **Default Value** into the reference variable *first*, then runs the match and overwrites it only if a match was found. So when the pattern misses, the variable is left holding exactly what you typed into `Default Value` (serialised as `RegexExtractor.default`), the sample stays successful, and the next request cheerfully sends that placeholder. If `Default Value` is blank and **Use empty default value** is unticked, the extractor writes nothing at all and the variable keeps whatever it already had. Either way the run records no error; only a `Response Assertion` on the field you actually needed would.
go deeper
Remember that extractors and assertions do different jobs: one copies a value out of a reply, the other decides whether the reply was acceptable. Only the second can turn a sample red.
Explain that process() writes Default Value into the variable before matching and only overwrites it on a hit, and that a blank default with the empty-value box unticked writes nothing at all.
Trace the chain from a missed match to a whole run of well-formed, meaningless requests, and say which assertion you would add and what default value makes the failure visible.
Set the convention for what a default value means across a team's plans, so that a marker such as NOT_FOUND is recognisable in every report rather than invented per plan.
A missed extraction is the quietest failure a JMeter plan can produce. Nothing turns red, nothing is logged at error level, and the run finishes with the error count it would have had if everything worked. ## Why an extractor cannot fail a sample `RegexExtractor` is declared as `class RegexExtractor extends AbstractScopedTestElement implements PostProcessor`. Post-processors are invoked by `JMeterThread` through `runPostProcessors(pack.getPostProcessors())`, which calls `process()` and ignores whatever it does. The only element type wired into the verdict is the assertion, through `processAssertion`, which computes `result.setSuccessful(result.isSuccessful() && !(assertionResult.isError() || assertionResult.isFailure()))`. So the failure modes divide cleanly: - **A bad pattern** — the regex compiles but matches nothing. Silent. - **A malformed pattern** — `MalformedCachePatternException` is caught and logged as `Error in pattern:`. Still silent as far as the sample verdict goes. - **A wrong reference name downstream** — also silent, because an unset reference simply renders as its own text. None of those three produce a failed sample or an error row. ## What Default Value actually does The order of operations inside `process()` matters more than most people expect: 1. Read the `Default Value` field (`RegexExtractor.default`). 2. If it is non-empty, **or** the *Use empty default value* box is ticked (`RegexExtractor.default_empty_value`, default `false`), write it into the reference variable straight away — before any matching happens. 3. Run the match. 4. On a hit, overwrite the variable with the generated result; on a miss, leave the default sitting there and remove the group variables. That pre-write is what makes the default reliable, and it is also what makes it dangerous. The variable is guaranteed to hold *something* after the extractor runs, so every downstream `${...}` reference resolves and every downstream request looks well formed. The blank case behaves differently and is worth knowing: | Default Value | Use empty default value | What the variable holds after a miss | |---|---|---| | `NOT_FOUND` | either | `NOT_FOUND` | | blank | ticked | the empty string | | blank | unticked | untouched — whatever it held before | ## The false-green chain The run that **reported zero errors while serving error pages** shows the whole chain in one plan. The login sampler received a `200` carrying an apology page instead of the token JSON. JMeter's status rule passed it. The Regular Expression Extractor looking for the token found nothing and wrote its default. The checkout sampler sent the default in an `Authorization` header, and the server answered that with another polite `200`. Every step was green, every step was wrong, and the numbers in the report describe the cost of serving error pages rather than the cost of checking out. ## Making a miss visible Three habits close the gap, in increasing order of effort: - **Choose a default you can assert on.** `NOT_FOUND` or `EXTRACT_FAILED` is far better than a blank or a plausible-looking dummy token, because a Response Assertion can then test for its absence and a Debug Sampler makes it obvious at a glance. - **Add the assertion that the extractor implies.** If the plan cannot continue without a token, a Response Assertion on `Text Response` matching the token's shape belongs on the same sampler. The extractor states an intention; only the assertion enforces it. - **Validate the plan at one thread before the load run** and read the Debug Sampler output, so the default never reaches a real run in the first place. ## What to say in an interview The sentence that shows you understand the design is: *extractors and assertions are different element families, and only assertions can change a verdict.* Follow it with the pre-write detail — the default lands in the variable before matching, not after — because that is the part that explains why a missed extraction produces a well-formed, wrong request rather than a visibly broken one.
- What does the Use empty default value checkbox change when the pattern misses?It makes the extractor write an empty string into the reference variable. Without it, a blank Default Value means the extractor writes nothing at all, so the variable keeps its previous content or stays unset. The box is stored as `RegexExtractor.default_empty_value` and defaults to `false`.
- How do you make a missed extraction actually fail the sample in JMeter?Attach a Response Assertion to the same sampler, testing the field you needed — typically `Text Response` with a pattern only a genuine reply contains. Choosing a distinctive Default Value such as `NOT_FOUND` also lets a later assertion match on that marker directly.
saying these in an interview costs you the question
- Says a failed extraction fails the sampler
- Thinks Default Value applies only in GUI mode
- Believes an unmatched regex writes an error row
- Assumes a blank Default Value clears the variable
- Confuses the default with an assertion's expected value