Retry on failure vs. risk of duplicate writes – choose idempotent design or manual guard

Answer

Use Gatling’s tryMax wrapper together with a manually generated idempotency key. Retry only on transient failures (5xx, timeouts) and treat 4xx—including 409 Conflict—as terminal for that logical write. Gatling does not provide a safeWrite helper, so the key must be created and kept constant across retries.

How Gatling decides to retry

Gatling’s tryMax re‑executes a wrapped chain when a check fails or an exception is thrown. There is no declarative “retry‑on‑status” DSL; you control retry by making checks succeed for statuses you want to ignore and then branching to stop further attempts.

Confirmed facts from Gatling

• No built‑in safeWrite or automatic idempotency‑key injection.
• Idempotency key must be supplied per virtual‑user attempt (feeder or exec) and reused unchanged across tryMax iterations.
• The semantics of tryMax, checkIf and session handling have evolved across Gatling 3.x releases.

Step‑by‑step pattern for this case

1. Generate a unique idempotency key for each logical write (e.g., UUID) and store it in the session via a feeder.
2. Define the request with the header Idempotency-Key: ${idempotencyKey}.
3. Add a status check that treats 200, 201 and 409 as non‑fatal for retry logic: .check(status.in(200,201,409)).
4. After the request, use checkIf or doIf to detect a 409 and set a session flag (e.g., retryAllowed = false) so that subsequent tryMax iterations are skipped.
5. Wrap the request in tryMax(3) and place the flag check inside the wrapper so that only transient failures (5xx, timeout, exception) trigger another attempt.
6. If the target API does not support idempotency keys, the safest approach is to disable retries on POST endpoints entirely.

Missing diagnostic detail

To fine‑tune the DSL, could you confirm which Gatling version you are using? The exact syntax for tryMax and conditional checks varies between 3.x releases.