agent loop detected: redeploying the same failed worker bundle every pass

TL;DR

Stop the loop and require a diff before any redeploy: the agent must change code, config, or the deploy command itself, and record what changed. A redeploy with byte-identical inputs is not a retry, it is a loop. Gate every deploy on "what is different since the last attempt" and cap consecutive identical deploys at two.

agent loop detected: redeploying the same failed worker bundle every pass

1. Halt the loop immediately. Do not run wrangler deploy again until a change is staged.

Expected: no new deploy attempts appear in the log. The bleeding stops.

1. Capture the exact failure signature: the full error text, the bundle hash or version ID, and the exit code from the last attempt. Write it to the run log.

Expected: one canonical failure record the next attempt must differ from.

1. Diff the inputs. Compare the bundle, wrangler.toml, and the deploy command against the previous attempt (git diff, or hash the bundle before upload).

Expected: the diff is empty, which proves the loop. If the diff is non-empty, this was not a true loop; treat it as a normal failed retry instead.

1. Form a new hypothesis that the last attempt did not test. Examples: the error names a binding, so check the binding in the dashboard rather than redeploying; the error is a limit, so shrink the bundle or split the worker instead of re-uploading the same bytes.

Expected: a written hypothesis that points at a changed input, not a repeated one.

1. Apply exactly one change, verify it differs (new bundle hash, edited config line), then deploy once and read the new error.

Expected: either a new error (progress) or success. The same error with the same hash means the change did not actually take effect; investigate the build step.

Use this when

• Deploy logs show identical errors across passes with no code change.
• The agent's plan says "retry deploy" with no new diagnosis.
• Bundle hashes or version IDs repeat in consecutive attempts.

Not for this skill when

• Each attempt changes something and fails differently. That is productive iteration, not a loop.
• The failure is transient (network blip, API 500) and a plain retry is legitimate. Loops are about identical deterministic failures.
• A human is driving the retries deliberately. This skill is for autonomous loops.

Variant phrasings

• agent keeps deploying same failing worker
• deploy retry loop identical bundle
• autonomous agent stuck redeploying broken worker
• wrangler deploy same error every attempt no changes

Why it happens

Agents treat "deploy failed" as a retryable step without checking whether the inputs changed. Deterministic failures (bad config, missing binding, oversized bundle) fail identically every time, so the retry policy becomes an infinite loop that burns API quota and buries the real error under pages of identical output. The missing piece is a pre-deploy gate: no diff, no deploy.

Edge cases

• Caches can make a changed source produce an identical bundle (stale build cache). If the agent did change code but the hash repeats, clear the build cache and rebuild; the loop detector should hash the bundle, not the source tree.
• Flaky infrastructure can make identical inputs fail differently, which looks like progress but is not. Require the error text to change, not just the attempt count.
• Some loops alternate two failing states (deploy A fails, "fix" to B fails, revert to A). Hash the full input set including config, not just the bundle, to catch oscillation.
• Rate limits punish loops fast. After a loop is detected, back off before the next real attempt so the retry does not trip the API limit on top of the original failure.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_mJq8qHNVsEeQc86Yc3yy5g