Photo by Hans Eiskonen / Unsplash

Clearing Cloudflare's Cache

Articles Apr 24, 2025 (Apr 24, 2025) Loading...

Swift note, more for me than for you. But still for you.

I was working on a web page https://exercises.workroomprds.com/comparing_generated_code/D/, and found that hacks on changes to the underlying javascript src/js/main.js didn't seem to stick.

Initially, I noticed because the app on the page gave me an error message, right there in the output, and the app wasn't usefully responsive. Digging into the error, I saw that a necessary function was being called without parameters – and it was doing that because I'd uploaded an old version of some code. Or, rather, I'd uploaded that version to the wrong place. It was an evening of mistakes. I re-uploaded the right file (which might, just might, have had a timestamp before that of the wrong one...).

The problem persisted.

I looked a the file via the browser's devtools, and saw the old version. I looked at the file via ftp, and found the new version. I'd not made another mistake in my upload.

I requested the file directly via its url in the browser, and got an old version. I requested the file with a suffix ?a=1 and got the new version. I suspected a cache.

I looked at the behaviour on a different device, and on a different browser, and saw that the error persisted. I looked at the file via devtools on that device, and saw the old version of code. I suspected a non-local cache.

I changed the time on the file / re-uploaded the file. Nothing made an immediate difference. I wondered what cacheing was on, that didn't pay attention to file changes.

I took stock. There are several caches – likely more than I imagine. Caches are obscure by design, and change over time, so this would need to be an opportunistic search, rather than a painstaking process.

I considered:

  • a local cache (in my browser, or on my machine). I looked here first, and stopped considering it seriously when I saw seen the error persist when on a different machine.
  • a server-side cache (this site is served by apache). I looked here second, and put it to one side because cacheing is complex and I thought I'd try to discount another before looking here.
  • a CDN cache (this site goes through Cloudflare). I looked here next. I've not looked at Cloudflare's cacheing before: I was interested by the novelty and wondered what it might do to make things simple.

On Cloudflare's site, I found cacheing information when I went to look at the configuration for workroomprds.com. Within configuration I saw Purge Cache.^

I chose Custom Purge, entered the problem URL (you'll see that in my 'recently purged' below), and waited a few seconds as recommended.

The problem persisted.

I did the same again, and the problem was gone.

That may, of course, be a coincidence. The cached file might have been replaced without any direct action by me – and the cache that needed a nudge might not have been Cloudflare's cache. But now I have a note on how to purge Cloudflare's cache.


Why is this important to me?

I have workshops where code can change, on this server, during my workshop. I want participants to have a friction-free experience. I don't want to be faffing about with caches, or with unnecessary problems, when I'm trying to give my attention to a room full of people. So I want to give some thought to all the caches that might banjax the experience for me and for them, if I insist on having code that can change while we work in the workshops.

Also... I want testers to understand more about cacheing, and I want to give them something to play with. I don't want them to play with my site, but perhaps I can think of something.


Pottering further through Cloudflare's cache configuration for workroomprds.com, I notice that I turned this off in 2016.

Perhaps I should turn it on for workshops where the code changes. And then manage the server cache and any triggers to local caches...

Member reactions

Reactions are loading...

Sign in to leave reactions on posts

Tags

Comments

Sign in or become a Workroom Productions member to read and leave comments.

James Lyndsay

Getting better at software testing. Singing in Bulgarian. Staying in. Going out. Listening. Talking. Writing. Making.

Great! You've successfully subscribed.
Great! Next, complete checkout for full access.
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.