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

Goal

We need to load‑test an API that performs non‑idempotent POSTs while still allowing transient failure retries.

Constraint

Retries must not cause duplicate side‑effects; the API only guarantees idempotence when an idempotency key header is present.

Unresolved Decision

Should we rely on Gatling’s retry DSL combined with manual idempotency‑key handling, or should we avoid retries altogether for write endpoints?

Specific Questions

• Can Gatling’s retry be configured to exclude status codes such as 409 Conflict from retrying a write request?
• Does Gatling provide a higher‑level helper (e.g., safeWrite) that automatically injects idempotency keys or tracks successful writes?
• What is the recommended pattern for ensuring a POST is retried only when the target server confirms the write did not succeed, without relying on server‑side idempotency?