Single file cache purging not always working

I have noticed that single file cache purging on the free plan has recently intermittently stopped working. The last time I noticed this there was a bug that effected the free plan only (see #281900).

This seems to happen when the same file is purged more than once in quick succession. Is there any rate limit on the number of times a single file cache purge can be called on the free plan? I can see the Cloudflare API is returning a 200 on each occasion the cache is purged but the CDN is still serving up old content. Any help would be much appreciated!

When a responsecode 200 is generated the request must be executed. But keep in mind that the 200 code just means your request was accepted, there is a 30s windows in which the cache then will be purged.

Does this occure just if used the API or also when using the Dashboard?

Thanks @M4rt1n, I’m using the API. I have noticed the old content is still served after the 30 seconds window.

Can you please doublecheck the header of the file when calling it and posting the header here, right after purging it’s cache, when it should be updated?

Here’s the cache headers for the file:

alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400
cache-control: public, max-age=0, s-maxage=604800
cf-cache-status: HIT
date: Tue, 18 Jan 2022 16:00:42 GMT
expect-ct: max-age=604800, report-uri=“https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct
last-modified: Tue, 18 Jan 2022 15:59:07 GMT

These headers haven’t changed and the single purge cache has been working well over the last few years, even when called several times in a minute.

This is not the full header. Please provide us with the URL you are talking about and purge cache before so we can test against a not cached version.

Ok, I need to reproduce the issue to get the headers again. Will update the thread once I do.

Just provide us with the URL and purge cache. Then I will check if the URL gets flushed. Also the ray-id (header) when this happens is usefull for the tech support, since it may is a local issue.

Hi @M4rt1n, thanks for your help yesterday. I’m not able to reproduce this again today. A few of my users have reported a problem over the last week or so, and I have witnessed the stale resource after they have reported it. I’ll report back with a purge cache ray-id when it happens again.

Just to confirm it’s the CF-Ray header on API responses in the format ‘6d01759e7d52418a-AMS’?

Will you also need the CF-Ray header on the subsequent GET request to the resource?

You are welcome!

Actually I would need the whole response header. As screenshot like this would be perfect. Just create one the next time when you notice such a behaviour.

Here what we need:


All of this as screenshot, optionally the full URL, so we can inspect it from our side.

Great, understood, thanks again for your help. I’m happy to close this thread to stop it hanging around.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.