Manually flush cloudflare cache on release?

[MylesBorins]

I've been noticing it taking quite a bit of time for new releases to propogate to the index For example we just released v14.7.0 and https://nodejs.org/download/release/latest-v14.x/ is still showing v14.6.0

My gut is this is related to our CDN cache, perhaps we should manually flush it on release?

[rvagg]

It shows 14.7.0 now, but I'm 7h removed from this original comment so it'd be interesting to know how long that took if anyone happened to notice.

There should be a maximum of a 5 minute delay for pushing a full CDN purge request to CF after someone promotes a build. I've now got logs so at least I can trace it! Here's the most recent:

2020-07-29T15:35:01+00:00, nodejs, promote 
2020-07-29T16:05:01+00:00, nodejs, promote 
2020-07-29T16:35:01+00:00, nodejs, promote 
2020-07-29T18:45:01+00:00, nodejs, promote resha_release 
2020-07-29T18:50:02+00:00, nodejs, build-site 
2020-07-29T18:55:01+00:00, nodejs, build-site build-site 
2020-07-29T19:00:01+00:00, nodejs, build-site 

The most interesting one is ~7h20m ago from when I'm writing this, there's two reasons given for a CDN purge, one is from builds being promoted (presumably the manual promotion) and the other from the signed checksums being pushed by the releaser, resha_release, so we know it's manual. Then following that we see a bunch more as the website got rebuilt (likely triggered by noticing a new version and then triggered by people pushing blog updates and ... more updates?).

The timestamp on the signed SHASUMS is 18:40, so there's a full 5 minute delay at play here (our crontab runs on 5 minute intervals, this one hit it at the start of a cycle so had to wait the full 5 minutes, on average it'd be 2.5m delay obviously).

That log entry is done immediately prior to a curl to CloudFlare. We have no indication of what the response to that might be. I've just done one manually using the same procedure and got a success:true, so I'm going to assume it's still working in general.

@jbergstroem we're doing a {"purge_everything":true} to https://api.cloudflare.com/client/v4/zones/${zone_id}/purge_cache for this. There's no way that might be interpreted as anything other than everything even with your recent tweaks to our cache rules is there?

[jbergstroem]

There's no way that might be interpreted as anything other than everything even with your recent tweaks to our cache rules is there?

Nope, this will zap everything.

[MylesBorins]

of course y'all are already doing it 😊.

Does cloudflare have a similar "immediate" cache flush option as fastly does?

I could imagine that we could make things a bit better by doing a more aggressive flush on particular routes... Specifically:

• https://nodejs.org/download/release/
• https://nodejs.org/download/latest-v*.x
• https://nodejs.org/download/latest-${lts-name}
• https://nodejs.org/download/index.json
• https://nodejs.org/download/index.tab

[rvagg]

It should be pretty immediate, I think the call goes out to invalidate all of the edges when we send it, at least that's how I've seen it work. The 5 minute delay is on our end for dedupe and security reasons.

We've been discussing more selective flushes for a while now and there's enough awkwardness involved that we've yet to pull it off. But the timing would still be the same even when we get that implemented.

[MylesBorins]

Honestly 5 minutes is not the end of the world.

We should just document it.

[jbergstroem]

FWIW, this is part reason I want to move all downloads to a subdomain: have better control of caching (#2375).

[mhdawson]

I agree with @MylesBorins that 5 mins is not all that long

[github-actions]

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.