Caching issue with Custom Domain for preview branches
We followed this guide: https://developers.cloudflare.com/pages/how-to/custom-branch-aliases/
Setup
Preview Branches:
dev & staging
Production branch: prod
- we have set this under our Workers & Pages / <pages name> / Settings
- we are not using git integration. We have CI pipelines that use wrangler pages deploy along with --branch and --commit-hash to ensure we push to the appropriate CD Branch.
For our 3 environment names we have custom domain assigned
- each custom domain is a hostname we use Cloud Flare to manage our DNS for. Following the instructions, we created the custom domain from our workers and pages app. Then for the preview branches, we went to our DNS records and updated the target to be dev.<page-name>.pages.dev and staging.<page-name>.pages.dev.
- As per the CF documentation we have left them proxied:
Currently, this setup is only supported when using Cloudflare DNS. If you attempt to follow this guide using an external DNS provider, your custom alias will be sent to the production branch of your Pages project.Our custom domains look like: - app.<domain> -> prod (CF branch name) - app-dev.<domain> -> dev - app-staging.<domain> -> staging Problem On our preview sites (
app-dev.<domain> and app-staging.<domain>) we have noticed that cloudflare is returning inconsistent files. Most of the time it returns the correct file deployed to environment branch.
- Sometimes the file request returns with 404 status when a file only exists on the preview branch but has not made it to prod
- Sometimes the file request returns the prod version of the file instead of the dev or staging version. For example one of our bundle files is statically named: service-worker.js. And we have a unique identifier inside of it per release which allows us to confirm we're getting the prod file when we should be getting the preview version.
We've tried:
- purging cache (everything)
- cache rules to bypass everythingCloudflare Docs
Add a custom domain to a branch · Cloudflare Pages docs
In this guide, you will learn how to add a custom domain (staging.example.com) that will point to a specific branch (staging) on your Pages project.
1 Reply
Hi, we've also started running into what sounds like the exact same issue.
We have custom domains pointed at pages deployments as follows:
<domain> -> client-<page-name>.pages.dev (prod)
dev.<domain> -> dev.client-<page-name>.pages.dev (staging)
The cloudflare provided page urls work fine, but on the dev domain there are a number of files that can't be found and return our index.html. This is leading to a bunch of errors where our code receives html but is expecting a different data type:
Refused to execute script from <js-file> because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.
ChunkLoadError: Loading chunk <chunk-num> failed.
SyntaxError: Unexpected token '<', "<!doctype "... is not valid JSON
- Sometimes the file request returns with 404 status when a file only exists on the preview branch but has not made it to prod - Sometimes the file request returns the prod version of the file instead of the dev or staging version. For example one of our bundle files is statically named: service-worker.js. And we have a unique identifier inside of it per release which allows us to confirm we're getting the prod file when we should be getting the preview version.This is a really interesting observation and makes me feel better that it's hopefully just an issue with our dev subdomain🤞 Nearly all of our files that have changes get a new hashed name so I was only noticing the 404 case, but it would make sense if it's trying to request files that don't exist on prod. These issues only started a few days ago for us. We've had this setup for over 2 years and have never run into anything like this. Did something change recently? @Sean were you able to figure this out? If not, some outside help would be greatly appreciated 😄 Oh also worth noting we don't have any custom caching rules and have tried cache purging everything, which didn't work