What does JMeter's Result Status Action Handler add over the Thread Group's error action?

## What it is for The Thread Group's error field is all-or-nothing: one policy for every sampler the group runs. The **Result Status Action Handler** is the targeted version. You place it where you want the reaction, and only the samples in that element's scope can trigger it. Under a single HTTP Request it watches that request; under a controller it watches the samplers in that branch. That is the whole of its value proposition, plus a slightly richer menu. ## The seven choices | Choice | Effect on a failed sample | |---|---| | `Continue` | nothing; this is the default | | `Break Current Loop` | leaves the innermost enclosing loop, like a `break` | | `Start Next Thread Loop` | abandons the rest of the thread-group iteration and begins the next | | `Go to the next iteration of Current Loop` | ends the innermost enclosing loop's iteration, like a `continue` | | `Stop Test` | the run winds down once in-flight samples finish | | `Stop Test Now` | the run stops abruptly, interrupting samplers where possible | | `Stop Thread` | this thread exits | The two loop-control choices — `Break Current Loop` and `Go to the next iteration of Current Loop` — are the ones you cannot reach from the Thread Group panel at all. They are the difference between abandoning the innermost loop and abandoning the whole thread-group iteration, which matters as soon as a plan nests a Loop Controller or a ForEach Controller inside the group. ## How it actually works This is the part that catches people out. The element appears in the **Post-Processors** submenu and the component reference documents it in the post-processor section, but the class does not implement the post-processor interface at all — it implements the sample-listener interface. The consequences are worth spelling out: 1. It is compiled into the sample's listener list, not its post-processor list. 2. It therefore runs **after** the post-processors and **after** the assertions, so it sees the final verdict, including a verdict an assertion flipped to failed. 3. It never stops anything itself. On a failed sample it sets a flag on the `SampleResult` — stop-thread, stop-test, stop-test-now — or records a logical action for the loop cases. 4. The thread reads those flags immediately afterwards and does the actual stopping. That ordering is exactly why it works: an element that ran before the assertions could not know whether the sample was going to be judged a failure. ## In the saved plan The element is one integer property, and the numbers are stable across versions: ```xml <ResultAction guiclass="ResultActionGui" testclass="ResultAction" testname="Result Status Action Handler" enabled="true"> <intProp name="OnError.action">4</intProp> </ResultAction> ``` `0` is Continue, `1` Stop Thread, `2` Stop Test, `3` Stop Test Now, `4` Start Next Thread Loop, `5` Go to the next iteration of Current Loop and `6` Break Current Loop. Note that the element's saved name is `ResultAction`, not the display name, which is worth knowing when grepping a repository of plans. ## When to prefer it, and when not to - Prefer it when exactly one step in the flow is the one that must not be survived — a login, a token fetch, a cart creation — and every other failure in the group should be recorded and ignored. - Prefer it when you need `Break Current Loop` or `Go to the next iteration of Current Loop`, which the group-level field cannot express. - Do not prefer it when the condition is anything other than 'this sample failed'. It has no expression field. A conditional stop that depends on a variable, a response value or a counter belongs in an If Controller wrapping a Flow Control Action instead. Because it is quiet — it adds no sample of its own and shows nothing in a listener — a plan that has one buried under a controller can be genuinely confusing to inherit. Name it for what it guards.