tryMax(3) retrying a POST creates duplicate records when the first attempt timed out server-side

Scenario

I have a Gatling simulation (3.x line) that wraps a write request in tryMax(3) so transient failures don't fail the whole scenario. The wrapped chain is a POST /orders with a status.is(201) check. The API under test is not idempotent and has no deduplication on its side.

Problem

When the first attempt succeeds on the server but the response is lost (client-side timeout), tryMax re-sends the entire POST, and the server persists a second order. From the client side there is no way to tell whether the write landed, so the retry decision is ambiguous. The report also shows inflated request counts for this endpoint, which makes per-attempt latency hard to read.

I considered keying the retry only on transport-level failure versus on specific statuses, but statuses like 409 or 5xx still leave "did the write happen?" undecidable from the simulation.

Questions

• Is generating a unique idempotency key per virtual user/iteration (via a feeder or session attribute) and sending it as a header the accepted pattern here, assuming the server can deduplicate on it?
• If the server cannot be changed, is the only safe option to exclude non-idempotent writes from tryMax entirely?
• Does tryMax offer any hook to distinguish attempt outcomes beyond the embedded checks, or is that out of scope for the DSL?