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

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

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

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

Thread query: agent loop detected: purging the cache API after every deploy, masking the real bug

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.