What this prompt does
This prompt makes the model a senior systems engineer and asks for a reusable retry-with-backoff wrapper in bash, safe to drop into production scripts and CI. You set [command_type], [shell_target], and [max_attempts], and it returns a retry() function taking max attempts, base delay, and max delay; exponential backoff with jitter; respect for the wrapped command's exit code; an optional per-attempt timeout; clear per-attempt logging to stderr; and safety under set -euo pipefail.
The structure works because deploy and bootstrap scripts fail for boring, transient reasons — a registry hiccup, a not-yet-ready service — and a blind retry loop just hides the real errors. Jitter avoids thundering-herd retries, the per-attempt timeout stops a hung command blocking forever, and respecting exit codes means it returns immediately on success. [command_type] shapes the usage example, [shell_target] keeps it compatible with your shell and OS, and [max_attempts] sets the default attempt count. The "which failures NOT to retry" note is as important as the retry logic itself: retrying a client error or an auth failure burns time and buries the real cause, so the prompt makes that distinction explicit rather than leaving you to discover it during an outage.
When to use it
- Your deploy or CI scripts fail on transient hiccups and a blind loop hides real errors.
- You want exponential backoff with jitter to avoid thundering-herd retries.
- You need a per-attempt timeout so a hung command can't block the pipeline forever.
- You want clean per-attempt logging to stderr but silence on the happy path.
- You're wrapping a flaky HTTP call and want it retried only on genuine failure.
- You want one wrapper that's safe under
set -euo pipefailacross your scripts.
Example output
Expect the retry() function itself, a usage example wrapping a flaky [command_type] call (such as a curl to an API), and a note on which failures you should NOT retry. The function logs each attempt — attempt N of M, the delay, the exit code — to stderr, stays quiet when the command succeeds first try, and returns the wrapped command's own exit code.
Pro tips
- Set
[command_type]to the real thing you're wrapping so the usage example matches your case. - Match
[shell_target]to your environment; the prompt can avoid bash 5-only features where reasonable if you need broader compatibility. - Tune
[max_attempts]to the failure you expect — transient network blips want a few tries, not twenty. - Read the "don't retry these" note carefully; retrying a 400 or an auth failure just wastes time and hides a real bug.
- Keep the per-attempt timeout enabled so a hung upstream can't stall your whole pipeline.
- Don't suppress the stderr logging — it's how you tell a transient retry from a failure that needs you.
- Set base and max delay to sane values for your
[command_type]; a registry pull tolerates longer backoff than a fast health check. - Drop the function into a shared helper sourced by your scripts, so every deploy gets the same retry behaviour instead of each one reinventing it.
