Duplicate writes in Jenkins Pipeline retry step during transient failures

The goal is to use the Jenkins Pipeline retry step to handle transient failures without causing duplicate writes to external resources such as files or database records.

The retry step re‑executes the entire block on any exception up to the configured count, and it does not provide a built‑in option to check whether a side‑effect has already succeeded or to skip re‑execution after a partial success.

Because Jenkins offers no native idempotency guarantee, users must make the block idempotent themselves or rely on the RETRY_COUNT environment variable, yet it remains unclear whether any core mechanism exists to detect prior successful writes automatically.

Is there a built‑in way to configure the retry step to avoid re‑executing the block when a write has already succeeded?

Can the retry step be extended to skip re‑execution based on detection of a prior successful side‑effect without requiring external tracking?