Duplicate writes when using travis_retry on non-idempotent shell commands

When using the travis_retry helper to handle transient failures, the goal is to retry a failing shell command without causing duplicate side effects from non‑idempotent operations such as database writes, file appends, or external API calls.

The helper retries the entire process but does not wrap the command in a transaction, roll back partial changes, or provide a way to detect whether a previous attempt already performed a write. This leaves open the question of how to safely retry non‑idempotent steps without external guards.

Are there any Travis CI environment variables or flags that indicate a command is being executed as part of a retry? What patterns can be employed within the build script to make such steps idempotent without relying on external state‑tracking tools? Is there a documented way to limit retries to only the command’s exit status while suppressing duplicate side effects?