Cache issue on Netlify?

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.

Thanks

Hi Giles,

As far as I can tell, that x-nf-request ID was

…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 :+1:

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 :exploding_head: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.

Any idea why this might be happening?

Thanks

After hunting through the Support Guides I just came across [Support Guide] Why do I see “Uncaught SyntaxError: Unexpected token <” errors? How can I use chunking or versioning for my assets at Netlify?

Just to clarify, should we be disabling filenamehashing in vue-cli to rectify this issue @fool? Configuration Reference | Vue CLI

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?

Thanks

Hey @Dennis, wondering if you could chime in on the above if poss please?

After reading you article on Uncaught SyntaxErrors I’d like to clarify next steps.

Is it ok to disable filenamehashing in vue-cli even though we are using dynamic imports to do a bit of code splitting?

Thanks

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.

I’m also assuming the site uses the single page application rule (aka SPA rule) below:

/*    /index.html   200

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 :+1:

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.

Hi @gilesbutler!

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.

It might look like this: https://5e85abb1a640d40006504f77--cms-demo.netlify.com/
You get them by clicking on the timestamp on a finished deploy in the deploy overview.

This url will always point to the same set of files - remember: Netlify deploys are atomic.
If you now start to use this URL to reference any Javascript entrypoint for your app, you should not experience files disappearing while people still have your app open.

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:

<script src="https://5e85abb1a640d40006504f77--cms-demo.netlify.com/js/main.js></script>

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.

The key to this is service workers. Browsers can check for updates in service workers and notify your client-side javascript if there is a newer version available. There is a great article about the service worker lifecycle.
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.

2 Likes

Hey @marcus, that’s super helpful thank you.

I’ll take a look at both of those options and figure out the best path forward.

If I come across anything useful I’ll post it back here for others in the future.

Thanks

1 Like

This issue is not solved. I am opening a new thread here to discuss my own specific issue with caching, URL rewrites and deploying via Netlify CLI:

https://answers.netlify.com/t/index-html-being-cached-and-served-instead-of-js-css-files/30139

Hi, @netlfynoob.

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.

Netlify has definitely a cache system issue!

If I dont clear my browser cache, I see some missing images on my site after a rebuild.

I dont want to force my users to clear their browser cache after each new build.

Hi, @herve76. About this:

Netlify has definitely a cache system issue!

I hear this a lot and in the majority of cases the person saying this is wrong. It is true that sometimes there are issues which are Netlify’s fault but this is the exception and not the rule.

However, just like with the person above, I’m happy to troubleshoot with you to prove what the root cause is. In all too many cases though, the issue is with the way the site is designed and has nothing at all to do with Netlify.

Looking at your site I see two things that jump out.

  1. It uses a service worker.
  2. The image URLs contain hashes. An example path being:
    • /assets/static/switzerland.b598514.da314c35ddfbe8424e882a7f349d6a1f.svg

Now, whether or not those are the cause or not isn’t proven yet. Would you be willing to make a HAR recording of the issue and post it here?

If so, it will contain the information required to prove what the cause is.

You can post that information publicly or you can private message (PM) that to one of our support staff. I’ve confirmed that PMs are enabled for your forum login. Please keep in mind that only one person can see the PM and this will likely mean a slower reply than posting the information publicly. Please feel free to reply to however you prefer though.

Hi Luke! I am facing the same issue! I use netlify cli to deploy my site. I have added --prod flag for production release. But cdn cache gives 404.

This seems to be a bug to me. Please help me clear the cdn cache…
x-nf-request-id: 01FX3J02T0D43D8GTKVZG5ZAE5

I found a solution. The issue was with “Asset optimization” in build and deploy settings.


Everything works well as expected if the asset optimization is disabled.

1 Like

Thanks so much for coming back and letting us know! Glad everything is working for you now.

Hi there, feels like I have a cache problem. I’ve updated the build and it was successfully deployed and published, the deploy preview shows correct website version, but the real website has the previous version still. I tried to use “clear cache and deploy site” feature, but the result was the same.

Do you have any suggestions?

Hi, @Anton_Kuropiatnik. In order to troubleshoot we need to know how to find the incorrectly cached response.

In order to troubleshoot this, we need to be able to track the HTTP response with this issue. The fastest way to do this is to send us the x-nf-request-id header which we send with every HTTP response.

There more information about this header here:

If that header isn’t available for any reason, please send the information it replaces (or as many of these details as possible). Those details are:

  • the complete URL requested
  • the IP address for the system making the request
  • the IP address for the CDN node that responded
  • the day and time of the request (with the timezone the time is in)

If you send us that information we can research this to find out what happened.