Your team's JMeter scripts reach through ctx into the thread and engine objects. Where do you draw the line?

Every JSR223 element gets `ctx`, and `ctx` is a door onto the running engine. Deciding how far a test plan may walk through that door is a standards call, because nothing in the tool enforces it and nothing in the `.jmx` makes the reach obvious to a reviewer. ## What is behind the door `JMeterContext` exposes, among others: - **Data:** `getVariables()`, `getProperties()`, `getPreviousResult()`, `getCurrentSampler()`, `getPreviousSampler()`, `getSamplerContext()` - **Identity:** `getThreadNum()`, `isSamplingStarted()`, `isRecording()` - **Control flow:** `getTestLogicalAction()`, `setTestLogicalAction(...)` — plus `setStartNextThreadLoop(...)`/`isStartNextThreadLoop()`, which 6.0.0 marks `@Deprecated` in favour of `setTestLogicalAction(TestLogicalAction)` and `getTestLogicalAction()`; they write and read the same `testLogicalAction` field, and `JMeterThread` switches on that enum, never on a boolean - **Handles:** `getThread()`, `getThreadGroup()`, `getEngine()` The class's own javadoc says it *"is not thread-safe - it is only intended for use within a single thread"*, and a set of its mutators carry *"Internally called by JMeter, never call it directly"* — `setVariables`, `setPreviousResult`, `setCurrentSampler`, `setThreadNum` among them. Those two lines give you a defensible boundary that is not a matter of taste. ## A tiering that survives review | Tier | Members | Rule | |---|---|---| | Green | the data and identity accessors | use freely | | Amber | `setTestLogicalAction`, `getSamplerContext` | allowed with a comment saying why an element could not do it | | Red | `getThread()`, `getThreadGroup()`, `getEngine()`, and every setter marked internal | needs a named owner and a review | `setStartNextThreadLoop(...)` is not a tiering question. It is deprecated in 6.0.0 and sets the same field `setTestLogicalAction` sets, so a plan still calling it earns a one-line substitution first — and the amber rule then applies to the `setTestLogicalAction` that replaced it. The argument for the split is not aesthetic. Green members read state the plan already owns. Amber members duplicate something JMeter models as an element — a Flow Control Action, an assertion, a Thread Group's error action — and moving that decision into a script hides it from anyone reading the tree. Red members hold references to the engine, and a script that calls into them binds the plan to internals that carry no compatibility promise across JMeter versions and that no reviewer sees in the diff. ## The trap worth writing into the standard `ctx.getThreadNum()` is **zero-based**, while `${__threadNum}` is **one-based**. The manual calls this out under the function. Any plan that mixes the two — a script picking a data slice by `ctx.getThreadNum()` and a label built from `${__threadNum}` — is off by one, and it will look like a data problem rather than an indexing problem. Pick one source of the number per plan and say which. ## Making the rule enforceable 1. **Prefer the element.** If JMeter models the behaviour as an element, the element wins; a script reaching `ctx` for it needs a reason in a comment. 2. **Name the values, not the path.** A script should take what it needs from `vars` and `props` and write back to `vars`. That keeps the coupling at the level of named values a reviewer can grep. 3. **Grep the plans.** `.jmx` files are XML with script text inline, so `grep -F 'getEngine()' *.jmx` across the repository is a real check you can run in a pipeline. 4. **Review the scripts, not just the tree.** A plan diff shows a script block changing as one opaque string; the reach it adds is invisible unless someone reads it. 5. **Write down the pinned version.** Green-tier accessors are stable public API; red-tier reach is what breaks on an upgrade, so the standard should say which JMeter version the plans are tested on. ## Where the line honestly moves There is no single right answer, and two defensible positions exist. A team maintaining one product's plans for years can afford a broader amber tier, because it upgrades JMeter deliberately and owns the fallout. A platform team publishing shared fragments to many consumers should be stricter, because their consumers cannot see or fix the reach. The judgment call is who pays when an upgrade changes engine internals — and the standard should name that person before the upgrade, not after.