## 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

```text
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

```bash
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