Which values can a Gatling Expression Language string produce on its own with no Session attribute behind it, and how many values does `#{randomUuid()}` yield when it appears twice in one URL?

Most Gatling placeholders read something the virtual user already carries. A second family manufactures a value instead, which is how a simulation gets a unique identifier, a timestamp or a random number without a feeder file and without dropping out of the Expression Language. ## The generators that ship in the 3.15.x line | expression | produces | |---|---| | `#{currentTimeMillis()}` | the current epoch milliseconds | | `#{currentDate(<pattern>)}` | now, formatted with a `java.time` `DateTimeFormatter` pattern | | `#{randomUuid()}` | a random UUID string, built fast from a thread-local generator | | `#{randomSecureUuid()}` | a UUID from the JDK's own `UUID.randomUUID()` — slower, cryptographically secure | | `#{randomInt()}` / `#{randomInt(min,max)}` | a random `Int`, full range or bounded | | `#{randomLong()}` / `#{randomLong(min,max)}` | a random `Long`, full range or bounded | | `#{randomDouble(min,max)}` / `#{randomDouble(min,max,digits)}` | a random `Double`, optionally capped to *n* decimal places | | `#{randomAlphanumeric(length)}` | a random alphanumeric string of that length | Three details about the bounded forms are worth memorising: * **The range is half-open.** `#{randomInt(5,10)}` returns 5, 6, 7, 8 or 9 — never 10. * **Negative bounds are legal**, so `#{randomInt(-10,-5)}` is a valid expression. * **An inverted range fails when the expression is compiled**, not during the run. `#{randomInt(20,1)}` raises an `ElParserException` while the simulation is being built, so the run never starts. The `randomDouble` forms are equally strict about their literals: each bound must be written as digits, a dot, digits — `0.42` is accepted, `.42` and `2.` are not. ## Each occurrence is evaluated on its own An EL string is compiled once, into a list of parts, and then evaluated per use. A generator part calls its generator every single time it is evaluated. The consequences are the ones people get wrong: 1. **Two occurrences in one string disagree.** `"/orders/#{randomUuid()}?trace=#{randomUuid()}"` sends two different UUIDs. If the path segment and the trace header must match, generate the value once — save it into the Session with a function — and read it back with an attribute placeholder in both places. 2. **A retry is a new value.** A request re-executed inside a retry block resolves its expression again, so an idempotency key written as `#{randomUuid()}` changes on every attempt, which defeats the point of an idempotency key. 3. **Nothing is memoised across a scenario.** `#{currentTimeMillis()}` at step one and step ten give different numbers, which is usually what you want and occasionally not. ## The date pattern is a `java.time` pattern, with one parser limit `#{currentDate(<pattern>)}` formats `ZonedDateTime.now()` with a `java.time.format.DateTimeFormatter` pattern, so the letters are the JDK's: `yyyy-MM-dd`, `HH:mm:ss`, `'T'` for a literal T. Two practical points: * **The pattern is read straight out of the expression, so it may not contain `#`, `{`, `}`, `(` or `)`.** Those characters are what delimits the expression itself. Everything else, dots and quoted literals included, is fine. * **The value is produced when the request is built**, not when the simulation starts, so a long-running scenario sees the clock advance between its steps. ## Combining a saved value with a generated one The everyday shape is one attribute the scenario captured earlier plus one value invented now: ```java exec(http("Create order") .post("/accounts/#{accountId}/orders/#{randomUuid()}") .body(StringBody("{\"placedAt\": \"#{currentDate(yyyy-MM-dd'T'HH:mm:ss)}\"}")) .asJson()); ``` `accountId` comes out of the Session — it was saved by something earlier in the scenario. `#{randomUuid()}` and `#{currentDate(...)}` are produced on the spot. The two kinds of placeholder are written the same way and can sit side by side in one string. ## Choosing between the two UUID functions `randomSecureUuid()` delegates to the JDK's `java.util.UUID.randomUUID()`, the standard RFC 4122 version-4 generator. `randomUuid()` assembles the string itself from a thread-local random source; Gatling documents it as *fast but cryptographically insecure*. Under load that difference is real — the secure generator draws from the system entropy source and is measurably slower at high arrival rates. The rule of thumb: * **Use `randomUuid()`** for values the system under test only needs to see as distinct — a correlation id, a cache-busting suffix, an order reference the test itself invents. * **Use `randomSecureUuid()`** when the value must be unguessable, or when something downstream validates the UUID's version and variant bits. ## Where the generators stop They cover timestamps, numbers and opaque identifiers. They do not build a value that has to look like production data — a plausible name, a valid postcode, a card number that passes a checksum. Nor do they express any conditional logic. When either is needed, the value belongs in a function or in feeder data, not in an expression string.