Retryable provisioners re-run non-idempotent steps without deduplication

Direct answer

Vagrant’s retryable option re-executes a provisioner after failure, but it does not wrap the run in a transaction, snapshot state, or suppress duplicate side effects. The safe pattern is to make the provisioner itself re-runnable: serialize with a lock, check a completion marker before doing work, publish outputs atomically, and write the marker only after success. For rsync-auto, the watcher re-invokes rsync after an interruption; it does not add an integrity gate, though rsync’s default transfer algorithm does not necessarily re-send the entire file. There is no confirmed on_retry hook implementation or release schedule in the available knowledge; treat it as an open design question and avoid retryable for non-idempotent side effects unless they are isolated behind a guard.

1. Making arbitrary shell/script provisioners safe under retry

Without external configuration-management tools, wrap the entrypoint so that a second run exits early when the first run already completed the same logical work. The wrapper must not mark completion before the side effect is durable.

#!/usr/bin/env bash
set -euo pipefail

STATE=/var/tmp/provisioner.state
LOCK=/var/tmp/provisioner.lock

exec 9>"$LOCK"
flock -n 9 || { echo "Another provisioner run holds the lock"; exit 1; }

# Skip if the marker matches the expected input version
if [[ -f "$STATE" ]] && [[ "$(cat "$STATE")" == "expected-input-hash" ]]; then
  echo "Already provisioned for this input"
  exit 0
fi

# Guarded steps: check-before-act, not blind append
if ! grep -q '^installed-marker' /etc/app/config; then
  tmp=$(mktemp /etc/app/config.XXXXXX)
  # write desired content to tmp, then publish atomically
  mv -f "$tmp" /etc/app/config
fi

# For API calls, record the request ID before calling and skip if present
if [[ ! -f /var/tmp/api-request.id ]]; then
  echo "req-$(date +%s)" > /var/tmp/api-request.id
  curl -X POST https://api.example.com/install \
    -H "Idempotency-Key: $(cat /var/tmp/api-request.id)" \
    -d @payload.json
fi

# Write the marker only after all side effects are durable
echo "expected-input-hash" > "$STATE"

Key rules: use flock to prevent concurrent runs; replace files with mktemp + mv -f rather than appending; use idempotency keys for external APIs; and write the completion marker last. A marker written before the side effect completes will cause retries to skip failed work.

2. rsync-auto integrity verification

rsync-auto does not add an integrity gate before retrying. After a change or interruption it re-invokes rsync. By default rsync uses size and mtime quick checks and delta transfer, so it is not forced to re-send every file. If --inplace is used, an interrupted run can leave a partial file at the final path; without it, rsync normally writes to a temporary file and renames, so the final path is replaced atomically.

To force content comparison, add --checksum through the synced-folder rsync args for your installed version (commonly rsync__args). Avoid --inplace when partial final files are unacceptable. Exact option names and defaults are version-sensitive.

# Inspect effective rsync behavior before relying on defaults
vagrant --version
vagrant rsync-auto --help

# Dry-run comparison after an interrupted transfer
rsync -n --itemize-changes --checksum ./src/ /vagrant/src/

3. Status of the on_retry hook

There is no confirmed on_retry hook implementation or scheduled release in the available knowledge. The current safe guidance is to avoid retryable for non-idempotent workloads, or to isolate those side effects in a non-retried provisioner or an external guard. Roadmap status can change; verify against the exact Vagrant release notes before promising behavior.

Verification and next step

To confirm the wrapper works, force a first-run failure in a retryable shell provisioner that appends to a file, observe the duplicate, then add the lock/marker/atomic-write wrapper and confirm only one effect remains. For rsync, compare -n --itemize-changes --checksum output with and without --inplace after an interrupted transfer.

One diagnostic detail would change the rsync recommendation: which Vagrant version and synced-folder rsync args option name are you using? Exact names such as rsync__args and default flags vary by release.