Cloudflare Cache Is Stuck
Hi - our Cloudflare Cache seems to be stuck for our page https://www.remnote.com/pricing. This URL is from a cloudflare pages deployment. Whenever we load it, we're seeing an old age of 90890 seconds (25 hours).
We've tried:
1. Purging our full Cloudflare cache
2. Purging cache for that specific URL
3. Enabling Developer mode
4. Deploying a new Pages build
Symtoms:
1. We're seeing this page return outdated HTML, but only in the united states. It's returning the correct HTML in Germany. In the US, we see cf-cache-status=DYNAMIC, but Age=91358, which we don't understand.
2. If we go directly to the URL of the underlying deploy, the returned HTML is correct.
Is there some way we can more forcefully purge the cache here? This is somewhat urgent for us. Thanks!
RemNote
RemNote — The all-in-one tool for thinking and learning
RemNote combines Notes, Flashcards, and PDF-Annotation.
10 Replies
Did you delete that page/asset (or switch to an SPA rather then static gen,etc)? That looks like static asset preservation cache
https://developers.cloudflare.com/pages/configuration/serving-pages/#asset-retention
Asset retention We will insert assets into the cache on a per-data center basis. Assets have a time-to-live (TTL) of one week but can also disappear at any time. If you do a new deploy, the assets could exist in that data center up to one week.
Thank you for the reply!
1. We hadn't deleted that page or switched to an SPA when this issue started.
2. An hour ago (after the issue started), we just deployed a new build that removed this page. This was an attempt to clear the cache & fix the issue. This does mean the route would now be served with our SPA instead of this file.
I'll revert that #2 change, and check the network logs when the page is restored.
These issues can occur because the cached response might get served to your end user before Pages can act on the request.I see this in those docs you sent. We don't have any Cache Rules enabled on our domain here. However, we do have this Page Rule that's caching the domain. Do we need to delete that Page Rule? Will Pages still cache everything itself? 🤔
Asset Preservation cache happens inside of the pages.dev. It has nothing to do with your caching, purging won't clear it, and you have no other way to clear it. so yea, I would revert the page and put the page's html back
Sadly your attempts to fix the issue just got you stuck way harder lol
Thanks!
Do you have any guess why the asset preservation cache would have been stuck in the first place? (Only in the US, not the EU). We've statically built this
pricing.html file in our build for every deploy for months, and hadn't made any changes there when this issue started happening.
(I'm especially confused because if we check the underlying https://709843b7.remnote-new.pages.dev/ deploy, it was returning a different HTML bundle from our custom domain remnote.com which was pointing at that bundle.)Do you have any guess why the asset preservation cache would have been stuck in the first place? (Only in the US, not the EU). We've statically built this pricing.html file in our build for every deploy for months, and hadn't made any changes there when this issue started happening.If the page existed and you were having this problem before it was unrelated to preservation cache. Preservation cache is per cloudflare pop/dc so locational makes sense.
(I'm especially confused because if we check the underlying https://709843b7.remnote-new.pages.dev/ deploy, it was returning a different HTML bundle from our custom domain remnote.com which was pointing at that bundle.)Preservation cache is a bit silly and uses the actual requested url as its index, so https://709843b7.remnote-new.pages.dev/pricing and https://www.remnote.com/pricing would be two unique cache keys, both living in the pages.dev cache, as weird as that is
This is really useful knowledge, thanks.
I can't find any docs on the "asset preservation cache". Is this actually using the Cache Reserve feature automatically through Cloudflare Pages? (We don't have Cache Reserve enabled for our account)
Nope, it's just normal cloudflare cache but lives on your pages.dev and is handled internally by Pages routing
page's request handler is all open source, can see it's logic and how it runs before the spa fallback: https://github.com/cloudflare/workers-sdk/blob/5936282bfbda848b465396a70f6334988d1a57a0/packages/pages-shared/asset-server/handler.ts#L639C1-L639C56
GitHub
workers-sdk/packages/pages-shared/asset-server/handler.ts at 593628...
⛅️ Home to Wrangler, the CLI for Cloudflare Workers® - cloudflare/workers-sdk
@Chaika Thanks so much for the insight, that analysis helped us solve it!