A Gatling simulation calling heavisideUsers(1000).during(20) stopped compiling after an upgrade — what happened to that injection step?
answer
- The step was renamed, not deleted
- Deprecated in one version, dropped later
- The old word survives internally
- heavisideUsers became stressPeakUsers in 3.7
basics
~10 sIt was renamed. heavisideUsers became stressPeakUsers in Gatling 3.7, kept only as a deprecated alias, and that alias was dropped in 3.11. Substituting stressPeakUsers is the whole fix; the arrival shape is unchanged.
solid answer
~40 s`heavisideUsers` was Gatling's original name for the S-curve open injection step. It was renamed to `stressPeakUsers` in **3.7**, where the old name survived as a deprecated, undocumented alias, and the alias was removed outright in **3.11**. On the current 3.15 line the identifier exists nowhere in the source tree, so the fix is a pure rename: `stressPeakUsers(1000).during(20)` takes the same arguments and produces the same distribution. Two things keep the dead name in circulation — a live Gatling tutorial page still lists `heavisideUsers` among its injection shortcuts, which is an upstream documentation defect, and the internal class is still called `HeavisideOpenInjection`, so the word still appears in stack traces from perfectly current code.
code
java · 23 linesimport io.gatling.javaapi.core.ScenarioBuilder;
import io.gatling.javaapi.core.Simulation;
import io.gatling.javaapi.http.HttpProtocolBuilder;
import java.time.Duration;
import static io.gatling.javaapi.core.CoreDsl.*;
import static io.gatling.javaapi.http.HttpDsl.*;
public class StressPeakSimulation extends Simulation {
private final HttpProtocolBuilder httpProtocol = http.baseUrl("https://example.org");
private final ScenarioBuilder scn = scenario("browse").exec(http("home").get("/"));
{
setUp(
scn.injectOpen(
stressPeakUsers(1000).during(Duration.ofSeconds(20))
).protocols(httpProtocol)
);
}
}go deeper
Be ready to recall that the S-curve step is spelled stressPeakUsers today and that heavisideUsers is a name from older Gatling versions.
Be ready to explain that this is a rename with no behaviour change, and to name the versions where the deprecation and the removal each happened.
Be ready to diagnose the failure from the compiler message alone and to say where you would look to confirm a symbol's fate across a version jump.
Be ready to set the team's policy on pinned versions, deprecation deadlines and which documentation is authoritative when the vendor's own pages disagree.
## What happened to the name `heavisideUsers` was Gatling's original name for the S-curve open injection step. It has been gone for several major versions, in two documented moves: | version | change | |---|---| | **3.7** | renamed to `stressPeakUsers`; `heavisideUsers` kept as a deprecated alias and removed from the documentation | | **3.11** | the deprecated alias dropped outright — the release notes read *"Drop deprecated `heavisideUsers`, use `stressPeakUsers`"* | On the current 3.15 line there is **no `heavisideUsers` identifier anywhere in the Gatling source tree**. A simulation that calls it fails to compile in Java, Kotlin and Scala, and fails at import resolution in JavaScript and TypeScript. There is no flag, no compatibility mode and no configuration key that brings it back. ## The fix is a pure rename ```java setUp(scn.injectOpen(stressPeakUsers(1000).during(Duration.ofSeconds(20)))); ``` `stressPeakUsers` takes the same arguments in the same order and produces the same arrival distribution: `n` users spread across `d` along a smooth approximation of the Heaviside step function, sparse at both ends and densest in the middle. Nothing about the profile changes, so no recalibration of the run is needed — the number of users started, the window occupied and the shape of the curve are all identical to what the old call produced. The rename applies to every SDK identically; there is no per-language variant of either name. ## Why the old name still appears to be current Two things keep `heavisideUsers` alive in front of engineers, and both mislead: 1. **Gatling's own documentation still teaches it.** A live tutorial page under `tutorials/test-as-code/java-jvm/full-sdk-capabilities` lists *"`heavisideUsers(x).during(t)` for S-curve ramps that avoid sudden jumps"* among its injection shortcuts. That page is not filed under release notes, so a search of the current documentation returns it as apparently current guidance. It is an upstream documentation defect, not a second supported spelling. 2. **The internal class kept the old name.** The class that `stressPeakUsers` constructs is still called `HeavisideOpenInjection`, so the word survives in stack traces, in `toString` output of an injection profile and in any log line that prints the step. Seeing "Heaviside" in a stack trace from a run that compiles is not evidence that the removed DSL method still exists. ## How to catch this class of breakage Every removal in Gatling is a **version claim**, and the failure mode is always the same: code that compiled against an older line stops compiling, with a message that names a symbol rather than a version. A few habits that make the upgrade cheap: - **Read the upgrade page for every major step you cross**, not only the one you land on. The 3.10 to 3.11 upgrade page carries the removal table that explains this exact failure. - **Trust the source tree over a tutorial page.** If a symbol appears in prose but nowhere in the API you are compiling against, the prose is stale. - **Pin the Gatling version explicitly** in the build so the line you compile against is a decision rather than a resolution artefact. - **Treat a deprecation as a deadline.** `heavisideUsers` was deprecated in 3.7 and survived four minor versions before it was dropped; a suite that fixed it in 3.7 never saw this failure at all. ## Confirming a symbol's fate in two minutes When a build breaks on a missing Gatling identifier, the fastest reliable check is mechanical rather than editorial: 1. **Search the artefact you actually compile against**, not the web. If the symbol is absent from the API jar on the classpath, no amount of documentation makes it available. 2. **Read the upgrade page for the version boundary you crossed.** Gatling publishes a removal table per major step; the 3.10-to-3.11 page carries this one, listing `heavisideUsers` explicitly. 3. **Distinguish the two failure directions.** Asserting that a removed identifier still works and asserting that a current one was removed are both defects, and neither is visible to a check that only asks whether the name appears somewhere. The word `heavisideUsers` still appears in Gatling release notes, in an upgrade table and in one tutorial page — an unanchored search finds all three and concludes, wrongly, that the method is present. 4. **Then fix the call site once.** A rename with no behaviour change needs no test adjustment and no rerun of a baseline; a behaviour change would need both, so it is worth establishing which one you are dealing with before touching anything else. ## What has not changed It is worth being clear about the blast radius. This is a symbol removal, not a behaviour change. The other count-based open steps in the same family — `nothingFor`, `atOnceUsers` and `rampUsers(n).during(d)` — kept their names throughout, as did the registering methods. If a simulation stops compiling after an upgrade and `stressPeakUsers` is the only substitution you make, the run it produces is the run the old code produced.
- Someone points at a current Gatling tutorial page that recommends heavisideUsers. How do you settle it?Check the API you compile against, not the prose. The identifier is absent from the 3.15 source tree, while the 3.11 release notes read "Drop deprecated heavisideUsers, use stressPeakUsers". A tutorial page outside the release notes can go stale without anyone noticing, and this one has.
- A run that compiles cleanly logs a stack frame mentioning HeavisideOpenInjection. Is the deprecated step still in use?No. `stressPeakUsers` constructs a class that kept the original name, so the word appears in stack traces, in an injection profile's toString output and in logs from entirely current code. The removed thing is the DSL method, not the implementation class behind it.
- Does swapping in stressPeakUsers change how the run behaves?No. It takes the same head-count and the same duration and produces the same smoothed Heaviside distribution, so the number of users started, the window occupied and the arrival curve are all identical. It is a symbol rename with no behavioural component, so no recalibration is needed.
saying these in an interview costs you the question
- Claiming heavisideUsers still works if you suppress the deprecation warning
- Reading a HeavisideOpenInjection stack frame as proof the old method survives
- Assuming the rename also changed the step's arrival distribution
- Trusting a tutorial page over the API actually on the classpath