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?
This problem mostly impacts sites that make heavy use of code-splitting in their frontend and have visitors staying a long time. We even ran into it on app.netlify.com which is also running on Netlify.
I think why it happens is pretty clear from the thread.
There are a few ways this problem can be solved. These can be combined.
Enforce the usage of the currently loaded deploy when people load the page
If you want to make sure that on loading the entrypoint html site for your app, people will only access the files of a single specific deploy, it is best to use the unique deploy url.
This url will always point to the same set of files - remember: Netlify deploys are atomic.
You can automate this using the DEPLOY_URL environment variable in your build.
Depending on your build setup you should be able to inject a value from an environment variable.
Your final script tag might look like this after inserting the env var:
Prompt visitors to reload the page if your app was updated
Many larger apps sometimes give you a notification that you should reload the page to get a new version of an app. You could implement the same for your app.
You should be able find resources about how to enable a service worker for your app. If you only want to use the service worker for the notification and not for offline caching, you might need to update the settings to disable local caching.
This might be jumping to conclusions as we have been debugging on the other topic and already found issues there that could explain this. We will keep debugging in the other topic and we can post an update here if there is actually a cache issue.