Does Gatling reset CSV feeder state between repeated simulation runs?

Direct Answer

No. Gatling 3.x does not reset CSV feeder state between repeated simulation runs executed in the same JVM (i.e., without forking). The feeder is a stateful iterator; its position is retained after the first run completes, so subsequent runs start where the previous one left off — often yielding zero records.

Why This Happens

• Feeders are implemented as Iterator[Map[String, Any]] instances.
• When a simulation runs, the scenario pulls records from that iterator until it is exhausted.
• If the same feeder instance is reused (typical when defined as a val in a singleton object or top-level object), the iterator is already at its end for the second run.
• This behavior is intentional: a single simulation execution is expected to consume the entire dataset.

Two Practical Fixes

Option 1 — Make the feeder circular

val feeder = csv("users.csv").circular

After the last record, the iterator loops back to the first. Caution: the simulation must have a stopping condition (maxDuration, fixed user count, exitHereIfFailed, etc.) or it will run indefinitely.

Option 2 — Recreate the feeder per run

// Define as a def so a fresh iterator is produced each time
def freshFeeder = csv("users.csv")

class MySimulation extends Simulation {
  val scn = scenario("Test").feed(freshFeeder).exec(...)
  setUp(scn.inject(atOnceUsers(10)))
}

Placing the feeder creation inside a def, a before {} block, or the simulation body ensures a new iterator for every execution.

Verification You Can Run Locally

1. Create a 3-record CSV (users.csv).
2. Write a minimal simulation that feeds from it without .circular().
3. Run mvn gatling:test twice in the same Maven session (no forkMode). Observe that the second run produces no requests.
4. Add .circular() or switch to a def feeder and repeat; both runs should now consume all three records.

When Forking Is Simpler

If you prefer not to change feeder code, configure the build tool to fork a new JVM per run:

• Maven: <forkMode>always</forkMode> in gatling-maven-plugin.
• SBT: fork := true in Gatling config.
• Gradle: forkEvery = 1 on the gatling task.

Each fork starts a fresh JVM, so feeder state is naturally reset. This is heavier than feeder recreation but requires zero code changes.

One Diagnostic Detail That Changes the Recommendation

Are you running simulations in parallel (multiple scenarios or multiple setUp blocks concurrently) while sharing the same feeder instance? If yes, you must use separate feeder instances per simulation to avoid race conditions on the iterator — .circular() alone does not solve concurrent access.