recovering-poisoned-asset-cache

First confirm whether a boot asset is returning a cached 404 by running curl -sI on the chunk URL and checking for HTTP 404 with cf-cache-status: HIT. If confirmed, purge the poisoned URLs at the CDN edge and rotate asset filenames so affected clients fetch new URLs.

Content hashes only change when file content changes, and vendor chunks like rolldown-runtime or vendor-vue-core come from node_modules, which a commit does not alter. Measured builds showed only 153 of 495 chunks rotating, leaving the poisoned vendor URLs identical after redeploy.

Set the ASSET_CACHE_BUST repository variable to a date like 20260818, which the build pipeline inserts into every emitted asset filename. This rotates all 495 hashed JS and CSS URLs while leaving non-hashed static files like favicon.ico unchanged.

No. A browser holding Cache-Control: max-age=2592000, immutable for a 404 will not revalidate, so no origin or edge action reaches that client. Only changing the asset URL itself, via a filename salt, forces the browser to request a fresh resource.

If a boot chunk 404s, no JavaScript executes, so no in-app error reporter ever fires and the error chart stays flat. Confirm recovery from the server side instead by monitoring the 404 rate on /assets/* requests.

It only affects content-hashed assets; non-hashed static files like favicon.ico, images, and CREDIT.txt keep their URLs. Also, the variable must never be cleared once set, because reverting restores the exact poisoned filenames and breaks clients still holding those cache entries.