HTTP 500 error during POST request in Gatling scenario

Goal

Implement retry logic for a POST request that may return an HTTP 500, while avoiding duplicate writes to the target API.

Constraints and Uncertainty

Gatling does not ship a built‑in retry directive; users typically build retries using exec, when, and session variable checks. Without an idempotency key, a retry can cause the same POST to be processed twice, leading to duplicate data on the server. The framework offers status checks and exitBlockOnError, but no global back‑off or retry limit configuration exists in the core codebase.

Specific Questions

• How can a Gatling scenario be structured to safely retry a POST that returns 500, ensuring the server receives an idempotency key on each attempt?
• Is there an established pattern for integrating exponential back‑off within the when blocks of a Gatling scenario?
• Does any recent Gatling release introduce a global retry configuration that could simplify this pattern?