Sampler Error Actions

## Where the setting lives Every Thread Group in Apache JMeter 6.0.0 carries a titled panel, **Action to be taken after a Sampler error**, holding five mutually exclusive radio buttons. It is not a property of a sampler and not a property of the Test Plan: it is one policy per Thread Group, applied to every sampler that group runs. In the saved plan it is a single string property on the group: ```xml <ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="Shoppers"> <stringProp name="ThreadGroup.on_sample_error">continue</stringProp> ``` The five accepted values are `continue`, `startnextloop`, `stopthread`, `stoptest` and `stoptestnow`. When the property is absent the engine falls back to `continue`, so a plan that never touched the setting behaves as if `Continue` were chosen. ## What counts as a Sampler error The trigger is the sample's final verdict, not the transport outcome. JMeter runs the sampler, hands the result to the post-processors in scope, then to the assertions in scope, and only then looks at whether the result is successful. That means all of these fire the action: - a request that never completed — connection refused, reset, read timeout; - a response the sampler itself judged unsuccessful; - a perfectly delivered response that a **Response Assertion**, **JSON Assertion** or any other assertion under that sampler marked failed. The component reference states it plainly: the action is taken 'either because the sample itself failed or an assertion failed'. ## What each choice does | Choice | `.jmx` value | Effect | |---|---|---| | `Continue` | `continue` | Nothing changes; the thread moves to the next sampler. | | `Start Next Thread Loop` | `startnextloop` | The remainder of this thread-group iteration is abandoned; the thread begins its next iteration. | | `Stop Thread` | `stopthread` | This one thread ends. Other threads are untouched. | | `Stop Test` | `stoptest` | Every thread is asked to stop; each finishes the sampler it is in and exits. | | `Stop Test Now` | `stoptestnow` | Every thread is told to stop and its in-flight sampler is interrupted where the sampler supports it. | ## The order that matters A common misreading is that a stop action discards the sample that caused it. It does not. Inside the thread loop the sequence for one sampler is: 1. serve the timers in scope; 2. run the sampler; 3. run the post-processors in scope; 4. run the assertions in scope, which may flip the verdict to failed; 5. notify the listeners — so the row reaches the results file; 6. *then* apply the error action. So the failing login, checkout or search sample is written to the JTL with its real verdict before the thread or the test is brought down. What you lose is everything the thread would have done *after* that sample. ## Practical notes - The setting is inherited by nothing. Each Thread Group in the plan has its own, and a plan with a setUp group, a main group and a tearDown group has three independent choices to make. - Third-party `jpgc` thread groups — the Concurrency, Arrivals, Stepping and Ultimate variants shipped by the plugins project, not by the Apache download — extend the same base class and carry the same `ThreadGroup.on_sample_error` property, so the policy travels with them. - If you need the reaction to apply to one sampler rather than the whole group, this field is the wrong tool; JMeter has a separate element for that, and a Flow Control Action under an If Controller gives you a conditional version. Because `Continue` is the default and it is silent, a plan whose author never opened this panel will keep every failing thread marching through the rest of its iteration — which is usually fine for a load run and almost never fine for a setup or smoke group.