In Gatling, why does a feeder declared as csv("users.csv").shard() still hand every virtual user rows from the whole file on a developer machine?

## What the option is for `shard` is a **feeder option** that marks a feeder's records as ones to be divided among the load generators of a **distributed run**. Gatling's documentation gives the arithmetic, under *Distributed files*: a file with 30,000 records deployed on 3 load generators means each generator uses a 10,000-record slice. That is what stops three machines from logging in as the same 10,000 users. Be precise about the **scope**, because the name and the documentation both point at files while the API does not. The method is declared on the **base** feeder builder — `FeederBuilder<T>.shard()` in the Java API that Java and Kotlin share, `FeederBuilderBase[T].shard` in Scala — and not on the file-based sub-interface, so `listFeeder(data).shard()` on an in-memory feeder and `jdbcFeeder(...).shard` on a JDBC one compile perfectly well. Contrast `unzip`, which genuinely is restricted to the file-based subtype. What is file-specific here is the documentation and the worked example, not the type; and off Gatling Enterprise every one of these is equally inert. Attaching it looks the same as any other feeder option: - Java, Kotlin, JavaScript and TypeScript: `csv("users.csv").shard()` - Scala: `csv("users.csv").shard` ## Why it does nothing on your machine The division is performed by **Gatling Enterprise**, not by the feeder. Gatling's documentation is blunt about it — the option is *"only effective when running with Gatling Enterprise Edition, otherwise it's just a noop"* — and the Java API repeats the same sentence in the method's own contract. Mechanically, the call sets a boolean on the feeder's options object. In the Community Edition the feeder sources that build the actual record iterator read the other options — the consumption strategy, the record transform, whether the file needs unzipping — and never read that boolean. It is written and never consulted. So the feeder behaves **exactly as it would have without the call**: every virtual user on that machine draws from the whole file, in whatever order the consumption strategy dictates. ## Three things it is not | people expect | what actually happens | |---|---| | deduplication, so no two users get one record | it never touches per-user allocation on one machine | | a change of consumption strategy | strategy is chosen separately; `shard` does not alter it | | a local slice of the file | there is no node count locally to slice by | The first of these is the costly one. A team that adds `.shard()` because two virtual users kept colliding on the same account will see no change, conclude the feeder is broken, and start debugging the wrong thing. ## The polarity trap: `shard` versus `noShard` Gatling has two sharding words and they point in opposite directions: | | feeder `shard` | population `noShard` | |---|---|---| | what it names | a feeder's records | an injected population | | default | **not** sharded | **is** sharded, on Enterprise | | the call's job | opt **in** to slicing | opt **out** of slicing | | off Enterprise | documented no-op | documented no-op | Read the pair once and it stays straight: you ask for your **data** to be divided, and you ask for your **load** not to be. ## What to do instead when you are hand-running several injectors If you are running Gatling's Community Edition on several machines yourself, `shard` will not separate their data and there is no other built-in that will. The separation has to come from outside the feeder: 1. **Give each machine its own file.** Split the data ahead of time and point each injector at its own path. Blunt, obvious in the artefacts, and impossible to get subtly wrong. 2. **Compute a slice in the simulation.** Read a node index and a node count from a system property or an environment variable, and take that slice of the records yourself before feeding them. `deploymentInfo` cannot supply those numbers off Gatling Enterprise — its generator index is hardwired to 0 and its generator count to 1 — so the numbers have to come from you. 3. **Make the data generated rather than shared.** Where the scenario allows it, deriving values per virtual user removes the collision problem instead of dividing it. Whichever you choose, the important part is that it is **visible**. A `.shard()` call that quietly does nothing looks like the problem is handled; a per-machine file path or an explicit node index does not. ## The version note worth carrying `shard` is current and unchanged on the 3.15.x line. It is worth saying so explicitly, because the neighbouring feeder **loading** modes were not so lucky: the `eager` and `batch` loading options were dropped in 3.15 in favour of an automatic threshold. `shard` is a different option, it is not deprecated, and it still means what it has always meant — just not on a single machine.