Self-Healing CI: Recovering a Slow CDN Purge
A post-deploy check that still sees stale content was usually just ahead of CDN propagation -- waiting for the purge to finish makes the check pass.
The problem
A post-deploy verification fails because a CDN cache purge or invalidation had not finished propagating, so the check still saw stale content. The deploy and the purge request both succeeded; propagation across edge nodes simply lagged. A human re-runs the check after a short wait and it passes unchanged.
AssertionError: expected new asset hash but got cached/old response
# the CDN invalidation had not fully propagated yetWhy it happens
A CDN purge is acknowledged immediately but propagates across many edge nodes asynchronously, so for a short window some edges still serve cached content even though the deploy and the purge both succeeded.
The lag is propagation timing, not a deploy failure: once the invalidation completes everywhere, the same check sees fresh content with no change to the deploy.
The manual fix
Manual handling for slow purge propagation:
- Re-run the post-deploy check after a short wait for propagation.
- Poll until the expected content is served instead of checking once immediately.
- Use cache-busting (versioned URLs) so verification does not depend on purge timing.
How this gets automated
A propagation lag is distinguishable from a failed deploy by whether the fresh content appears shortly after. A self-healing CI pipeline detects the stale-content condition, waits for the purge to propagate and re-checks, and only escalates if the content never updates, which is the real signal of a deploy problem rather than slow propagation.