A JMeter sampler has two Response Assertions and the second ticks Ignore Status. What happens to the first one's failure?
answer
- The property is named assume_success
- It runs before the patterns do
- Assertions are evaluated in order
- Status is carried forward and combined
- Manual says first assertion only
basics
~10 sIt is wiped. Ignore Status forces the sample back to successful before the second assertion evaluates its patterns, so the earlier failure no longer counts and the sample ends the run green.
solid answer
~50 s`Ignore Status` does not mean "ignore the HTTP status" in isolation — it means **set this sample successful before checking**. JMeter runs the assertions on a sampler in order and, after each one, keeps the sample successful only if it was already successful **and** the assertion neither failed nor errored. When the second assertion has `Ignore Status` ticked, the first thing it does is set the sample's status back to `true`, which discards the failure the first assertion had already ANDed in. If the second assertion then passes, the sample is recorded as a pass. The first assertion's failure message is still attached to the sample as an assertion result, so a listener shows it, but the sample's own verdict, and therefore the error counts and the pass/fail column in the results file, say success. This is why the manual says to put `Ignore Status` only on the first assertion of a sampler.
go deeper
Know that Ignore Status forces the sample to successful before the assertion checks anything, and that it is meant for samplers whose response is deliberately an error.
Explain the mechanics: assertions run in order, each verdict is ANDed into a status carried forward, and the reset discards whatever that status held, including an earlier assertion's failure.
Diagnose it in the field. Recognise a green sampler with a failed assertion inside it, know that the failure survives in listeners but not in the pass counts, and be able to grep Assertion.assume_success across a set of plans.
Turn it into a standard: at most one Ignore Status per sampler and always the first element, checked in review of the .jmx rather than the GUI, so no team's pass rate quietly stops meaning anything.
## What the checkbox really does The `Ignore Status` checkbox on a Response Assertion is stored as `Assertion.assume_success`, and the name of the property is the better description. When it is ticked, the very first thing the assertion does — before it reads a field, before it evaluates a single pattern — is force the sample's status to successful. That is genuinely useful. It is how you assert on a response that is *supposed* to be an error: a `403` sample is unsuccessful by default, so a plan that wants to verify the body of a `403` ticks `Ignore Status` and then asserts that the response code equals `403`. Without it the sample would be red no matter what the assertion concluded. ## Why order matters JMeter evaluates the assertions attached to a sampler **in order**, and after each one it recomputes the sample's status as: > the sample stays successful only if it was already successful **and** this assertion neither failed nor errored. That is a pure AND over a value that is being carried forward. Two consequences: - A failing assertion always reddens a sample, and nothing later can un-redden it — **except** an assertion that resets the carried value. - `Ignore Status` is exactly such a reset, and it does not distinguish between a failure that came from the HTTP status and one that came from an earlier assertion. It clears both. So the sequence for the scenario in the question is: 1. Assertion one evaluates, fails, and the sample's status becomes `false`. 2. Assertion two starts, sees `Ignore Status`, and sets the sample's status to `true`. 3. Assertion two evaluates its own patterns and passes. 4. The status is recomputed: `true` AND not-failed, so the sample is **successful**. ## What survives and what does not This is the part that makes the defect hard to spot: | Artefact | After the reset | |---|---| | The sample's own success flag | `true` — the run counts it as a pass | | The first assertion's result object | still attached, still marked as a failure | | Assertion Results listener | shows the first assertion's failure message | | View Results Tree | shows the sampler green with a failed assertion inside it | | Error percentage on a summary | unaffected by the failure | The evidence is all still there; nothing lies about the individual assertion. What the reset changed is the only number that gets aggregated. ## The rule that follows JMeter's manual states it twice, once under `Ignore Status` and once under *Patterns to Test*: ticking it cancels any previous assertion failures, so make sure it is only ever set on the **first** assertion attached to a sampler. That is a rule worth putting into a review checklist, because the GUI gives no hint of ordering risk — the checkbox looks local to the element it sits on. Practical habits that keep this from biting: 1. **One `Ignore Status` per sampler, and it is the first element.** If a sampler needs two assertions and one of them is checking a deliberate error response, that one goes first. 2. **Prefer scoping the deliberate-error check to its own sampler** where the plan allows, so no sibling assertion shares the reset. 3. **Review the .jmx, not the screenshot.** `Assertion.assume_success` is a plain boolean property in the file and is easy to grep for across a plan. 4. **Read the Assertion Results view, not just the pass count**, when validating a plan for the first time — a green sampler with a failed assertion inside it is the signature of this configuration. ## The same reset from script A JSR223 Assertion has no `Ignore Status` checkbox, but it is bound to the live sample as `SampleResult`, so a script can call `SampleResult.setSuccessful(true)` and achieve exactly the same reset, with the same effect on any failure recorded before it. That is worth knowing both because it is occasionally the cleanest way to express a conditional reset, and because it is one more thing to look for when a plan reports fewer errors than its assertion results suggest it should. ## The worked case A checkout sampler carries two Response Assertions: the first requires the body to contain `"orderId"`, the second — added later by someone verifying a rejection path — checks the response code and has `Ignore Status` ticked out of habit. From that commit onwards the order id check still runs, still fails on a broken response, and still shows its failure in a listener, but the run reports a clean pass rate. The check did not stop working; its verdict stopped counting.
- When is Ignore Status the right thing to tick rather than a mistake?When the sampler is meant to receive an error response and you want to assert on it. A `403` sample is unsuccessful on its status alone, so a plan verifying the rejection path ticks `Ignore Status` and then asserts that the response code equals `403`. Keep it on the first assertion of that sampler.
- Does the first assertion's failure disappear from the results entirely?No. The assertion result object stays attached to the sample and a listener such as Assertion Results or View Results Tree still shows its failure message. Only the sample's own success flag is reset, which is the value the pass counts and the error percentage are built from.
- How would you find every use of this checkbox across a directory of plans?Grep the .jmx files for the property `Assertion.assume_success` set to `true`. It is written as a plain boolean on each Response Assertion, so a text search over the plan files finds every one, including the ones whose GUI panel nobody has opened in months.
Ignore Status is a scorer wiping the board clean before recording the next result. The earlier round was still played and is still written in the match notes, but it no longer contributes to the score anyone reads.
saying these in an interview costs you the question
- Saying Ignore Status only affects the HTTP status code
- Assuming assertion order does not matter
- Thinking the earlier failure still counts somewhere aggregate
- Ticking it on every assertion out of habit
- Claiming a passing assertion always rescues a red sample