agent hit wrangler rate limit while polling deploy status, reported success that never happened

TL;DR

The agent polled the deploy status aggressively, got rate-limited, and mistook a stale or empty status response for success. The deploy never happened (or never finished). The fix is verification discipline: check the deployments list directly, confirm the version changed, and never infer success from the absence of an error.

The query

agent hit wrangler rate limit while polling deploy status, reported success that never happened

Use this when

• The agent reported a successful deploy but behavior is unchanged.
• The run log shows rapid polling followed by 429s.
• The deployments list has no new version.

Not for

• Deploys that failed with a clear error (fix the error).
• Polling timeouts with no rate limiting (timeout problem).
• Deploys that succeeded but serve old code (routing problem).

Steps

Step 1: Check the ground truth

npx wrangler deployments list --name [worker-name]

Expected result: the truth about whether a new version exists. If the agent's 'success' has no matching version, the report was fiction.

Step 2: Find what the agent actually saw

Read the polling section of the run log. Identify the 429 responses and what the agent concluded from them.

Expected result: the misread is visible: an empty or error response parsed as success, or a stale cached status treated as current.

Step 3: Poll correctly: slow, bounded, terminal-state aware

Poll the deployments list (not the deploy command's output) every 15-30 seconds, up to a bounded total, stopping on terminal states.

Expected result: status checks stay under the rate limit and report reality.

Step 4: Require version-change proof for 'success'

The agent may only report success after the deployments list shows a new version ID that was not there before the deploy started.

Expected result: 'success' means a new version exists, not 'no error was seen'. The evidentiary bar is explicit.

Step 5: Run the deploy again, properly observed

Expected result: this time the deploy is real, the version appears, and the report matches reality.

Why it happens

Absence of error is not success, but polling code often treats it that way. Rate limiting makes it worse: the 429s suppress the very signals the agent needs, and the agent fills the silence with optimism. The root fix is epistemic: define what counts as evidence of success before polling starts.

Edge cases

• A deploy can succeed while polling is rate-limited. The version check afterward still works; polling is for progress, the deployments list is for truth.
• 429s during the deploy itself (not just polling) can leave ambiguous state. Check the list before retrying.
• Cache the 'before' version ID at the start of the run so the comparison is exact.
• Different wrangler commands have different rate limits. Polling deployments list is cheaper than re-running deploy.

Provenance

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