A Gatling run stopped eight minutes into a planned thirty with 'Feeder csv(credentials.csv) crashed: feeder is now empty' — what outputs does that run leave you, and how do you size the file so the next one finishes?

## Read the message first The line names the feeder and, on the JVM SDKs, the source position of the `feed(...)` step that drew from it: ``` Feeder csv(credentials.csv) (defined at: LoginSimulation.<init>(LoginSimulation.java:28)) crashed: feeder is now empty. ``` That tells you which of the simulation's feeders ran dry — useful the moment there is more than one — and which `feed` step ran it dry. Read the position for what it is: the line that called `feed(...)`, captured while the DSL was building that step, **not** the line that declared the builder. On the usual layout — `FeederBuilder<String> credentials = csv("credentials.csv")` once, `.feed(credentials)` somewhere below — those are two different lines, and they coincide only when the builder is written inline inside the `feed(...)` call. The feeder in question is on the default **`queue`** strategy: every record goes out at most once, and the first `feed` call that finds the iterator empty stops the load generator. ## What the run left behind | artefact | present after a feeder crash? | |---|---| | raw per-run simulation log | yes, covering the eight minutes that ran | | HTML report | **no** — the run never reached report generation | | assertion results | **no** — assertions are evaluated after a completed run | | `after` hook side effects | yes, the hook still executed | | KO entries explaining the stop | no, nothing failed as a request | So the run has **no verdict**. That is the trap for a CI job: there is no failed assertion to catch, because assertions never ran. The failure surfaces as a crashed process, and a gate that only reads assertion output will report nothing rather than reporting red. The eight minutes of data are not lost, though — the raw log is on disk, and Gatling's `--reports-only` option will build the HTML report from it after the fact, which is usually the fastest way to see whether the part that did run was healthy before the data ran out. ## Size the file from the profile, not from the user count The stock is consumed once per **`feed` step execution**, so the arithmetic is: ``` records needed = (users started over the run) x (feed executions per user) ``` - In an **open** model, users started is the arrival rate integrated over the run — 20 users/sec for 30 minutes is 36,000 users, whatever the concurrency chart shows. - In a **closed** model you cannot read it off the profile at all: how many users complete a scenario in 30 minutes depends on how fast the target responds, so size against your worst-case (fastest) expectation, not your average. - A `feed` inside a loop multiplies by the loop count. Two `feed` steps in one scenario double it. - Two separately declared feeders over the *same* file do not share a cursor: each reads the file from the top, so the same credentials go out twice and your effective stock is not what you think it is. Declare the builder once and reuse that value. Then add headroom. A run sized to exactly the expected draw crashes on the first retry, the first ramp overshoot, or the first time someone lengthens the soak. ## Deciding what to change Growing the file is the only fix that preserves the property `queue` was chosen for. Before reaching for `circular` to make the problem go away, check what the records actually are: - **Identity-bearing records** — logins, single-use tokens, accounts a test mutates. Keep a consuming strategy and grow the stock, or shorten the run. Reusing these puts two virtual users behind one identity, and the target's own serialisation, token invalidation or duplicate-login rejection then shows up as latency and errors that look like a system defect and are not. - **Read-only or non-identifying records** — search terms, product ids, geographies. `circular` or `random` is the right answer and the crash should never have been possible; the file being small is then a feature. If the run genuinely needs more distinct identities than you can provision, that is a test-data conversation rather than a Gatling setting, and the honest report is that the run could not be executed at the requested size. ## Making the next failure louder The deeper problem with this class of failure is that it is silent until it is fatal: nothing in the report, the console or the statistics counts down as the stock drains, and the first news is the crash. Two habits help. 1. **Write the arithmetic down next to the feeder.** A one-line comment stating the profile the file was sized for makes the next person who doubles the arrival rate notice what they have just invalidated. 2. **Treat stock size as part of the profile, not part of the data.** When a run's duration or rate changes, the feeder file is one of the things that has to change with it, in the same review. And be explicit in the report you write afterwards: a run that crashed on test data did not measure the system, and the eight minutes it did produce are a partial observation at best — the tail behaviour a thirty-minute run exists to find is precisely the part that never happened.