## TL;DR

The symptom disappears after each deploy because the agent purges the cache, not because the deploy fixed anything. When the cache warms, the bug returns. The purge is masking a stale-cache or cache-key bug. Stop purging, reproduce with a warm cache, and fix the actual caching logic.

## The query

```text
agent loop detected: purging the cache API after every deploy, masking the real bug
```

## Use this when

- Deploys 'fix' the issue for minutes, then it returns.
- The agent purges cache as a standard deploy step.
- The bug only manifests with warm cache.

## Not for

- Legitimate invalidation when content actually changed (correct use).
- One-time purges during incidents (deliberate).
- Cache-key bugs with no purge involved (fix the keys directly).

## Steps

### Step 1: Stop the purge and reproduce warm

Deploy without purging, warm the cache with the failing request pattern, and observe.

Expected result: the bug reproduces reliably with warm cache. You now have a stable repro.

### Step 2: Inspect what the cache is actually storing

Check cache keys, vary headers, and TTLs for the affected paths.

Expected result: you find the real defect: wrong cache key collapsing distinct responses, missing vary on auth headers, or a TTL far longer than the content's freshness.

### Step 3: Fix the caching logic

Correct the keys, add the missing vary, or shorten the TTL. Purge once, deliberately, to clear the poisoned entries.

Expected result: warm cache serves correct content. The bug is gone with the cache warm, which is the real test.

### Step 4: Remove the purge from the deploy ritual

Expected result: deploys no longer purge. If content deploys need invalidation, make it targeted (exact keys) and explicit, not a blanket purge.

### Step 5: Add a warm-cache check to the deploy verification

Expected result: post-deploy checks run against warm cache, so a masking purge can never again fake a green deploy.

## Why it happens

Purge-then-verify is a comforting ritual: everything looks fresh and correct. But it tests the cold path only. The agent learned that purge makes the red go green and kept doing it, while the warm-path bug compounded. The loop is between the agent's verification method and the actual defect.

## Edge cases

- Some deploys genuinely require invalidation (renamed assets, changed APIs). Distinguish 'content changed' from 'bug hunt'.
- The Cache API purge and CDN cache purge are different operations. Know which one the agent was calling.
- Stale-while-revalidate patterns can also mask bugs; check those too.
- Log every purge with a reason. Unexplained purges in the log are the early warning for this loop.

## Provenance

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