A JMeter thread's login sampler fails, yet it keeps running the checkout samplers. How do you stop that?

## Why the thread carries on Nothing in JMeter couples one sampler's verdict to the next sampler's execution. The Thread Group's error field defaults to `Continue`, so after the login sample is recorded the thread simply asks its controller for the next sampler and runs it. With no session, the checkout requests fail as well, and the results file ends up with one failed login followed by a string of failed follow-ups per iteration — noise that hides the single real failure underneath it. JMeter gives you three levers, in ascending order of precision. ## Lever 1: the group-wide error action Set the Thread Group's **Action to be taken after a Sampler error** to `Start Next Thread Loop`. Internally this ends every loop on the path from the failing sampler back to the Thread Group and restarts the thread-group iteration, so the thread jumps straight to the top of its flow — back to the login. It is one radio button and it is honest about being coarse: it fires for *any* failing sampler in the group, not just the login. In the plan file it is a single value: ```xml <stringProp name="ThreadGroup.on_sample_error">startnextloop</stringProp> ``` ## Lever 2: a scoped handler on the login only Add a **Result Status Action Handler** under the login sampler and choose `Start Next Thread Loop` or `Stop Thread`. Now only that sampler's failure triggers the reaction; a flaky product-image request further down the flow is recorded and ignored, as it should be. This element also exposes `Go to the next iteration of Current Loop` and `Break Current Loop`, which the Thread Group panel does not offer — useful when the login sits inside a nested loop and you want to leave only that loop. ## Lever 3: an explicit conditional stop When the decision deserves to be visible in the tree, make it explicit: 1. after the login sampler, add an **If Controller** with `Interpret Condition as Variable Expression` checked and the condition `${__jexl3(!${JMeterThread.last_sample_ok})}` — the controller runs its children when the condition evaluates to `true`, and the bare `${JMeterThread.last_sample_ok}` is `true` when the sample *succeeded*, so it has to be negated; 2. inside it, add a **Flow Control Action** with `Action = Stop` and `Target = Current Thread`, or `Action = Start Next Thread Loop`; 3. leave the rest of the flow outside the controller. `JMeterThread.last_sample_ok` is the variable JMeter writes after every sample, holding `true` or `false`. The Flow Control Action is a sampler, but it produces no sample result of its own, so it adds no row to the results file. Its `Target` selector only applies to `Stop` and `Stop Now`; the loop actions always act on the current thread. ## Which lever to pull | Situation | Reach for | |---|---| | Any failure makes the rest of the iteration pointless | Thread Group set to `Start Next Thread Loop` | | Only one step is load-bearing for the rest of the flow | Result Status Action Handler under that sampler | | The condition is richer than “the sample failed” | If Controller plus Flow Control Action | | A broken login should abort the run before load starts | `Stop Test` on a setUp Thread Group | ## Two things that do not change - **The failed login is still recorded.** The error action is applied after the post-processors, assertions and listeners have run, so the row lands in the JTL with its real verdict. You lose the follow-ups, not the evidence. - **Nothing here retries.** None of these levers re-issues the login. JMeter ships no retry element and no per-sampler retry checkbox; what it offers is a way to stop wasting the iteration, not a way to have another go. A last practical note: whichever lever you pull, name the element for what it guards. `Start Next Thread Loop` chosen on a Thread Group is a single radio button three panels away from the sampler it protects, and the next person to open the plan will not go looking for it.