I made sure it’s not a local cache issue by opening the urls in another browser and inPrivate.
How can I purge the cache?
To see the difference, type “rub” into the search box. For “ru”, there are still two items showing on the preview and and unique deploy urls, but after entering “rub”, nothing should show. On the live url, when typing “rub”, all books are shown again (old behavior, before the deploy).
Hey @Pie I don’t have this option because I don’t have continues deployment set up (I deploy via CLI and not from Github). Do you know of any other option? I don’t see a way to clear cache in the docs.
Hey @Pie, thanks for the link. I followed the conversation there but it does not solve my problem because I don’t have a .cache directory anywhere connected to the Netlify deploy.
However, I left a comment there, saying just that, with the question on how to clear cache.
It just seems like a bug to me. I don’t see how anyone would ever want to keep an old version of a page online when doing a production deploy. I mean, since the new version is on the unique deploy url, but not on the live url. That seems like a bug. Wouldn’t you agree? I wonder where I should go with this, if it were indeed a bug.
caching of old assets on CDN nodes once a new version of the site is deployed
I believe this case is about the second type of caching, not the first. (Please correct me if I am mistaken though.)
The second type of caching shouldn’t occur and there is more about why in this blog post. All deploys are atomic at Netlify and previous versions of a site should be immediately invalided once a new deploy is published (due to the use of the etag HTTP headers as described in the blog post).
If you are being served an out of date asset, the best information we can ask for to troubleshoot is the x-nf-request-id HTTP response header which Netlify sends with every response.
There is more about this header here:
If this header for the incorrect response is not available, the following details are what it replaces and what we would request to troubleshoot further. Would you please send us the details below if the x-nf-request-id header isn’t found for any reason? (If you don’t have all the details, please send what you do have.)
the complete URL requested
the IP address for the system making the request
the IP address for the CDN node that responded
the day of the request
the time of the request
the timezone the time is in
To summarize, if an assets shouldn’t occur when a new version of a site is deployed. However, it is possible that this occurred even though it shouldn’t. To find out for certain, we’re happy to research the issue and resolve it (if it is an error at Netlify). In order to troubleshoot it, though, we’ll need the x-nf-request-id header or details above to investigate it further.
If there are any questions about this issue or the reply above, we’re happy to answer those as well.
Hi @luke, many thanks for the detailed response and willingness to troubleshoot this further, I really appreciate it!
The cache has been automatically invalidated in the meantime, without any more actions on my part. I also believe it was about the CDN cache. And I read in some article (don’t remember where exactly) that Netlify is different in that it automatically invalidates CDN cache upon deploy, which is what lead me to my suspicion that this is in fact a bug.
Should this happen again in the future, I would reply to this thread with all the details you described.
I ran a production deploy (netlify deploy -p), and I get two urls, the Unique Deploy URL and the Live URL. On the Unique Deploy URL (https://5e413690b7d212f1a4357bc5--determined-mahavira-b5e110.netlify.com) everything’s fine, the changes are visible. On the Live URL (https://determined-mahavira-b5e110.netlify.com), I get the old version of the page!
You can verify this by opening the console in the developer tools. When typing something into the search field, the characters will appear in the log. Also, there is no service worker present on the old version of the page. This is not a browser cache issue.
As described by you in the last post, I’m sharing the x-nf-request-id of the Live URL:
Here’s the x-nf-request-id of the Unique Deploy URL (where everything’s fine): e326b533-ac13-4c8b-a939-36d69ef70764-6973140
No it’s not a browser issue, and it’s not a service worker issue!
The latest deploy is the first version of the page that uses a service worker at all, and I made sure to use another browser to check the page.
If you open https://determined-mahavira-b5e110.netlify.com/ in any browser where you’ve never opened it before, you’ll also see console logs when typing something into the search field.
I wonder what the use case is for this feature? Because there is this cli command “deploy -prod” or “deploy -p”. I wonder in which scenario someone would want to have to go online and click a button to deploy to production?
Anyway, the latest deploy is not live. Thanks a lot for your help!
…so whatever you were seeing was either not about this file after all, or was anyway not about us serving not-currently-published content. Since that asset is no longer on the CDN, I did not have a great way to check for consistency on it, but I did check our internal logs over the past 48 hours and with the exceptions of a branch deploy for develop (https://app.netlify.com/sites/promo-newsletters/deploys/5e7594ae8f1cd00008b1b4ff) we served no other deploys during the past 48 hours than the two you had published (5e7596620db62100088cd779 and 5e7871c9ec62b70008eef556), and those had a pretty clean handoff at around 8am UTC on the 23rd.
Happy to keep digging if you come up with another asset that might be wrong! But I don’t see any evidence of wrong caching on that site in the past 48h.
Thanks so much for checking @fool, really appreciate it
Sorry I didn’t a notification of your response.
We haven’t had any more people complain about it so I’m putting it down to an issue on our end if everything was working on your side.
We have been getting the following issue a couple of times with deploys though. It looks like some of our customers get severed our index.html inside our app.js file It just happened to me on our development branch after deploying but I forgot to grab the x-nf-request-id sorry! After refreshing the page the x-nf-request-id for the newly deployed app.js is aa8be669-05d4-4e79-95cb-43a7527ac4a2-77991825 but the filename has updated to app.4a8abd73.js as it’s the new version. Screenshot below of the error.
Hi, @gilesbutler. Netlify deploys are atomic. When you deploy a site all files are included for that deploy. Any files for previous deploys no longer exist unless they also exist in the current deploy.
Do you know if this is already a solved problem with the Vue framework?