Run: 'always' vs 'once' — Choosing the Right Provisioner Strategy for Retry‑Safe, Non‑Idempotent Scripts

When a Vagrant machine fails to provision due to a transient network glitch or a synced‑folder mount error, the provisioner may be retried automatically. If the provisioner is configured with run: 'always', Vagrant will execute it on every retry, potentially causing duplicate writes such as appending timestamps or installing packages twice.

Setting run: 'once' lets Vagrant track the provisioner’s state and skip it after the first successful run, which protects against duplicate writes but also means the provisioner will not re‑run when a configuration change is introduced unless the user explicitly triggers a reprovision.

Because many provisioning scripts are not inherently idempotent, developers must decide whether to rely on run: 'once' and manually trigger reprovisioning, or to keep run: 'always' and implement idempotency checks inside the script. No built‑in Vagrant feature currently detects or suppresses duplicate writes for arbitrary provisioners.

What mechanisms can be added to a provisioning script to safely detect and avoid duplicate writes when run: 'always' is used? Does Vagrant provide any hooks or state flags that could be leveraged to conditionally skip non‑idempotent actions on retries? When should a user prefer run: 'once' over run: 'always' to balance safety and flexibility?