jsdelivr: Purging doesn't always work as expected (brings back older version)

Describe the bug I’m trying to setup a workflow where I’m loading a JSDelivr script from a 3rd party. I want this script to load the latest version of my master branch. The link of the script to load cannot change.

I have renamed the origin/main into origin/master to avoid JSDelivr to be confused.

I’m using console.log('testX') to track which version is being returned by JSDelivr CDN. I expect test7 to be the one that should be displayed. But it varies between test5 and test6 depending on which url I load.

At the time of writing, the file being loaded should contain test7. But, when loading https://cdn.jsdelivr.net/gh/UnlyEd/stacker-public-scripts/dist/univers-pps.js it shows test6.

If I specify the master branch’s name, it shows test5. https://cdn.jsdelivr.net/gh/UnlyEd/stacker-public-scripts@master/dist/univers-pps.js - I guess that’s because I didn’t purge.

I’m auto-purging when pushing changes into the master branch, using a github action that calls the purge endpoint. https://github.com/UnlyEd/stacker-public-scripts/runs/5273136959?check_suite_focus=true

I don’t specify the branch’s name when purging, should I always? Example: purge.jsdelivr.net/gh/UnlyEd/stacker-public-scripts/dist/univers-pps.js

I’m trying to find the best way to auto-purge when changes are made to the script, and I want to avoid running into the purge limit, I noticed there can only be 3-4 purge calls for the same url within an hour.

It’s weird that both links (one specifying the master branch and one not) do not have the same content, as they should both point to the same file, that means the purge doesn’t affect both. It’s counter-intuitive.

I’ve noticed the link https://cdn.jsdelivr.net/gh/UnlyEd/stacker-public-scripts/dist/univers-pps.js to change its content unexpectedly after purging, going from test6 (pre-urge) to test5 (post-purge) notably.

I wonder if there isn’t a better solution for my workflow.

Affected jsDelivr links

Response headers image

Screenshots If applicable, add screenshots to help explain your problem.

Please complete the following information:

  • Device OS: [e.g. iOS] MacOS
  • Browser: [e.g. chrome, safari] Chrome
  • Browser version: [e.g. 22] Latest
  • VPN provider if you use one: None
  • Your location (country): FR

Additional context Add any other context about the problem here.

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 25 (11 by maintainers)

Most upvoted comments

Right now this doesn’t always work as you expect when using @branch refs because purging applies only to the edge CDN servers, while the files may be cached - for a short time - also on the internal origin servers. A solution that works right away is using tagged releases that don’t have this problem.

Since this issue comes up often, we’re going to prioritize improving the way purge works with branches.

@ElektrikSpark the release numbers need to be valid semver to be considered for @latest. As your response headers show, you’re receiving the branch files:

x-jsd-version: master
x-jsd-version-type: branch

If I understand what you’ve said correctly, the “test10” should appear in ~12h.

That should be the upper limit yes. Or it would update now if you purged it again.

The problem happens only if:

  1. You request version X, our servers cache the list of versions for a short time.
  2. You publish version X + 1 right after.
  3. You call purge to get X + 1 before our servers update the version list.

Note that we return an “x-jsd-version” header which you could theoretically use to check if the purge worked in your script. If not, you could wait for 10 minutes and try it again. A bit more work but it should be possible to make it more resilient this way.

Update: I checked now and 10 minutes is the upper limit for version list caching. If the purge call is made 10 minutes after the release, the results should be 100% consistent. Shorter than that, there’s a small chance of the above situation.

I need to make some tests with this, it might be simpler and more reliable than purging.

Note that if you want immediate updates without changing the URL to include the exact version, you’ll still need purging. Otherwise, it’ll update in 12 hours.

https://cdn.jsdelivr.net/gh/UnlyEd/stacker-public-scripts/dist/univers-pps.js will check for valid semver tags first and use master branch only as a fallback, see https://github.com/jsdelivr/jsdelivr#use-a-version-range-instead-of-an-exact-version-only-works-with-valid-semver-versions. So you can make releases 1.0.0, 1.0.1, etc.