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 @Scott 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 @Scott, 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.
Hi, @glorifiedmonkey. As I commented on the other topic , there are two different types of caching being discussed here. Those two types of caches are:
the build cache directory /opt/build/cache
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:
b6b615f2-3130-4172-a77e-05e8b7eda2db-3441354
Here’s the x-nf-request-id of the Unique Deploy URL (where everything’s fine): e326b533-ac13-4c8b-a939-36d69ef70764-6973140
Hi, @glorifiedmonkey. Would you please take a look at the following Support Guide and let us know if the information there helps to resolve this issue?
Hi @luke
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.
@glorifiedmonkey, It looks like you the deploy you mentioned is not currently the ‘published’ deploy. You can see that here: Netlify App. If you want to make sure that your latest ‘prod’ deploy is automatically published, you can click the ‘Start auto publishing’. Let me know if that resolves your issue.
Hi @Dennis,
Indeed, I had to go to Netlify App/deploys/ and click “publish deploy” !!
I hope “Start auto publishing” will solve this.
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!
I also want to clarify that if using the Netlify CLI tool to deploy with the netlify deploy command, to publish the deploy to production it is required to use the --prod option.
If --prod is excluded it will make a deploy preview but it will not publish that deploy as the production version of the site.
This is in addition to auto-publishing being enabled for the site.
Hey @luke, sorry to hijack an old thread but I’m also seeing caching issues on Netlify.
We auto deploy by pushing to Bitbucket and letting Netlify pull down the code and do it’s thing.
Recently I’ve been getting complaints from customers as they couldn’t log in.
I replayed some of their sessions using LogRocket and I could see they were getting old versions of our Vue app. It wasn’t until they refreshed the page everything started working for them.
This is less than ideal as we’re a saas platform and some users have left us instead of refreshing the page as they had no idea what was going on.
Our current x-nf-request-id is eeb0b0f5-ec6a-40ae-83f7-f4857a887d8d-20725688 if that helps. Would love a hand getting to the bottom of what’s going on.
…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 (Netlify App) 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.
We do code-split and import some components dynamically though. It’s not clear based on that article if we should be doing this or trying to implement some sort of service worker?
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.
So, when a new deploy occurs the app.<previous_hash_here>.js file stops existing. So, index.html is served for that path instead of the expected javascript. It is a 404 not found being turned into a 200 with index.html because of the SPA rule.
The issue here, even without the filenamehashing, is that people that are in the middle of navigating the site will attempt to load the next chunk of javascript but the versions of that javascript have changed from what the currently loaded browser window expects. Hashed name or non-hashed name - either way - if the chunks have changed, there may be incompatibilities between the currently loaded javascript and the next chunk.
It seems to me that a key question here is: “How does the current page know when it’s javascript and therefore it’s references to other chunks is out of date and that he current javascript itself must be reloaded before navigating to the next route/page?”
My best guess would be that, before the site loads any new javascript, the browser would do a HEAD request on the currently loaded app.js asset and reload it if its etag has changed. I would hope that there is a built-in solution for this already in Vue but I’m not familiar enough with Vue to answer.
Do you know if this is already a solved problem with the Vue framework?
Hey @luke, thanks for the detailed reply, really appreciate it mate
Yep that sounds like the exact problem. I’ll do some research into a solution as I haven’t come across anything that’s built into Vue.
Isn’t this a common issue across all frameworks/JAM stack sites on Netlify though?
It feels a bit strange that it’s not more of an issue or maybe I’m doing something wrong on this end. I feel like more people would have come across it though ha.
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.