Netlify serve old cached version

[tcp]

Hey @Scott!

Unfortunately, it’s still the case for us. Just happened now, with multiple users.

[Scott]

Hey @tcp,

I ran tests earlier today and was able to identify that our CDN PoPs were all serving the same deploy. Is this perhaps client-side? Happy to test again if you can’t resolve!

[tcp]

Hey @Scott!

We had 2 websites deployed that used the same codebase. I guess only one of them was corrected – the other one was still facing difficulties earlier this week

Thank you for the help though!

[Scott]

Hey! If you’ve got a URL, I can take a look.

[oscar.carlstrom]

Hi @Scott

I’ve been having the same issue for some time now. Clearing the browser cache helps. But after a second (regular) refresh it’s back to the old version. Have tried clearing cache and redeploy, but without any luck. The site URL is: https://www.evasminnesfond.se/

My netlify.toml looks like:

[[headers]]
 for = "/*"
  [headers.values]
  Access-Control-Allow-Origin = "*"

Also noticed that my default subdomain https://sad-ramanujan-8a5890.netlify.app/ just crashes (just displays a white page), if i don’t do a hard refresh.

Would very much appreciate the help. Thank you!

[luke]

Hi, @oscar.carlstrom, I’m seeing that custom header returned when I test this site:

$ curl -svo /dev/null https://www.evasminnesfond.se/  2>&1 | egrep '< '
< HTTP/2 200
< access-control-allow-origin: *
< cache-control: public, max-age=0, must-revalidate
< content-type: text/html; charset=UTF-8
< date: Mon, 31 Aug 2020 04:24:44 GMT
< etag: "e471e38e38e2f67a2ddbd13daa161add-ssl"
< strict-transport-security: max-age=31536000
< age: 0
< server: Netlify
< x-nf-request-id: d16706a5-b176-4f72-aec7-e6b0b9eac131-8719323
<

I also checked the version of the site which was active when this post was made:

$ curl -svo /dev/null https://5f46663a9ae98ae7d3cd9aff--sad-ramanujan-8a5890.netlify.app/  2>&1 | egrep '< '
< HTTP/2 200
< access-control-allow-origin: *
< cache-control: public, max-age=0, must-revalidate
< content-type: text/html; charset=UTF-8
< date: Mon, 31 Aug 2020 04:25:42 GMT
< etag: "adf69840c74cbf1e8e220c18c58a8d4f-ssl"
< strict-transport-security: max-age=31536000; includeSubDomains; preload
< x-robots-tag: noindex
< age: 0
< server: Netlify
< x-nf-request-id: 63bb63b2-a5bd-452b-acbe-14d6d2ba54fb-18562360
<

That also shows the header being sent.

Are you still seeing this issue? If so, would you please send us the x-nf-request-id header for the response without the access-control-allow-origin header?

Regarding the site displaying just a white page, that I wasn’t able to reproduce. Would you please share instructions about how to trigger that behavior?

If there are other questions for us, please include those at any time.

[oscar.carlstrom]

Thank you very much @luke! No, not at the moment. But it seems to appear on every other deploy. Only to somehow be fixed after a while. Not sure if that is after a fresh deploy (changed files) or after some time has passed. Do you have any thoughts on that?

[luke]

Hi, @oscar.carlstrom, I don’t have any thoughts about it because I haven’t been able to see the issue happening.

If you send us the x-nf-request-id header for a response missing the header I can research it further. Without being able to see the issue happening, I’d only be guessing.

There more information about the x-nf-request-id header here:

[Support Guide] Netlify Support asked for the 'x-nf-request-id' header? What is it and how do I find it?

Last reviewed by Netlify Support staff August 2023 What is the x-nf-request-id header? Web servers and web browsers communicate using a protocol called HTTP - which stands for “HyperText Transfer Protocol”. Both web browsers and web servers use a feature called headers as part of this protocol. The headers that web browsers send are called “request headers” because the browser in making an “HTTP request”. The web servers headers are called “response headers” because web servers send an “HTTP …

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 of the request
• the time of the request
• the timezone the time is in

To summarize, I’m happy to troubleshoot but in order to do this I’ll need this data (the x-nf-request-id header or the information it replaces) to direct that troubleshooting.

[oscar.carlstrom]

Hi again @luke. Ran in to this issue once more on the last delpoy. An old version of the site is being served.

This is the x-nf-request-id: ea969fa8-5524-4054-b9f4-039d53efbb7f-3374883

Anything else you need, just let me know.

Cheers!

[luke]

Hi, @oscar.carlstrom. I checked the x-nf-request-id above. We didn’t serve that response today. The x-nf-request-id of " ea969fa8-5524-4054-b9f4-039d53efbb7f-3374883" was served on 2020-08-20 at 09:20:12 UTC, which is eleven days ago.

We did serve the site version which was deploy id 5f3e3fde5701ba000882e7a5 at that time. However, that was the currently published deploy at that time as the deploy with that id above was completed at 09:19:00 UTC (about a minute before the web request).

I’m not sure why the x-nf-request-id above is eleven days old. Do you have a service worker installed locally?

I don’t see one now but there could have been one before and your local browser is therefore caching page loads. That is the only reason I can think of that you would get such an old request id.

[oscar.carlstrom]

Thank you very much @luke! That explains it, yes I have. I tried out gatsby-plugin-offline a while back. And then removed it. I almost forgot about that.

Unregistered the service worker now, so it should help.

Thanks again!

[nord]

I get the exactly same issue. I can’t get the newest version on my chrome browser, even with hard-refresh, clearing cache locally, clearing cache on netlify, clearing cookies, etc. We don’t use a service worker and we haven’t specified custom caching headers.

However it works in other browser and in incognito. I have deployed multiple times with and without clearing cache and with new versions (changes in git), but I’m continually being served the old version.

I have even added some meta tags to the header with the COMMIT_REF value so I can see which version is served, but they never appear even appear (they do in incognito, so it should work).

Here is an request id for a request that does not work: x-nf-request-id: 4ce39d6e-364c-4c1a-b180-aeca1ebb22fc-21938284
Here is an request id for a request that works: x-nf-request-id: 4ce39d6e-364c-4c1a-b180-aeca1ebb22fc-21922364.

[luke]

Hi, @nord. I’ve redacted your site’s subdomain (like example.netlify.app) in the information below. Please replace example with the actual subdomain for your site to use any URLs below.

Long story short, you have split tests enabled for this site here:

https://app.netlify.com/sites/example/splits

The request for the x-nf-request-id ending 84 was at 2020-11-10 14:13:13 UTC for this deploy:

https://app.netlify.com/sites/example/deploys/5fa2cf779db0b200077f4fb1

That deploy id is the current deploy for the non-production branch in the split test (then and now).

The request for the x-nf-request-id ending 64 the deploy was at 2020-11-10 14:12:55 UTC returned the deploy below:

https://app.netlify.com/sites/example/deploys/5faa9f20e0c9190008cbd153

That is current deploy for the production branch (then and now).

To summarize, both requests do appear correct. There are two different versions being served depending on the nf_ab cookie value sent. If no cookie is sent, because the split test is 50:50, there is an equal chance for each version to be shown.

If there are other questions, please let us know.

[nord]

Thank you so much! And how embarrassing that I forgot about our split test But it makes sense, and we have updated our split test branch now. Thanks again for the support :)!

[lmolema]

Hi there. I’m experiencing the same issue with an old version thats being served for my site timpel.online.

This is the old x-nf-request-id: 678a4629-8c2a-41aa-83ff-12dd8f645336-2330847.

If I empty my cache and refresh I get the new version with x-nf-request-id: b9aa59ee-c91e-4ad5-a892-be1b2c44c5e0-37983793

Any clue how I make sure the old version gets invalidated?

Thanks in advance!

[Update]: I seem to have another working x-nf-request-id: 513bad84-9b48-4f01-bd42-36577b5c746d-7568515, that I got after a couple of hard refreshes. If I do a soft refresh afterwards I always get the old one ending on 847 again.

[luke]

Hi, @lmolema. This wasn’t a caching issue at Netlify. You have a local service worker installed and it is serving you the old version.

The following support guide has more information about how to find and remove the service worker:

[Support Guide] Understanding & unregistering service workers

Last reviewed by Netlify Support - August, 2023 A service worker is a script that your browser runs in the background to accomplish a variety of tasks. Browsers cache service workers for 24 hours by default, and don’t update them when you reload your page. Therefore, you may have a service worker on your site which could prevent you from seeing the latest and greatest changes that you’ve made. If you suspect a service worker is causing this issue, I recommend disabling/removing the service wor…

How do I know it is a service worker? There are two reasons:

1. The x-nf-request-id above (678a4629-8c2a-41aa-83ff-12dd8f645336-2330847) hasn’t been sent in the last 30 days. It is so old it is no longer in our logs at all.
2. We only send a x-nf-request-id one time. They are unique ids and specific to a single request. The same x-nf-request-id will never get sent twice.

If you are getting the the same x-nf-request-id on subsequent requests, the only possible explanation is a service worker.

If there are other questions about this, please let us know.

[MickPerez]

Hi Netlify engineers,

I’m running into a similar issue. According to the headers the served javascript is a day old Fri, 29 Oct 2021 13:18:38 GMT, whereas I deployed a new build on 30 Oct 2021 at 21:53 GMT using the option “Clear Cache and Deploy Site”.

I don’t understand why the latest version is not being served.

It concerns x-nf-request-id: 01FK637J0SD4SEYJHKXA65G1X5

Would appreciate if you could have a look. Thanks!

[luke]

Hi, @MickPerez. Our service will not cache content that far back and the date: header will still be the present date and time. The fact that you are seeing a date header from a month ago means it is nearly certain that response is coming from a local service worker:

[Support Guide] Understanding & unregistering service workers

Last reviewed by Netlify Support - August, 2023 A service worker is a script that your browser runs in the background to accomplish a variety of tasks. Browsers cache service workers for 24 hours by default, and don’t update them when you reload your page. Therefore, you may have a service worker on your site which could prevent you from seeing the latest and greatest changes that you’ve made. If you suspect a service worker is causing this issue, I recommend disabling/removing the service wor…

Would you please read that support guide and let us know if removing the local service worker resolves the issue or not?

If it does not resolve it, would you please make a HAR recording of the issue occurring and share that with us?

[MickPerez]

Hi Luke,

Appreciate your fast answer. I had a closer look and it seems like changes to the linked github repo are not getting through to the Netlify.

I tried everything. Renaming the specific javascript file, push in git, pull into live, build & deploy the website. Switch off asset optimization. Reconnecting the Netlify instance to the github repo. Clearing the cache & rebuilding, etc. etc. I think I spent 150 Netlify minutes on rebuilding & redeploying the Jekyll site.
To no avail.

And suddenly I noticed a new button in the Deploy view which I previously not seen.
The button was called “Publish deploy”.
OMG, are you kidding me?!?!

So I clicked the button… and lo and behold all my changes have been published.
I think during my frenzied attempts I might have clicked on an option somewhere to stop automatically publishing deploys/builds.

Anyway Luke, thank you at least for offering suggestions.

I hope someday, somewhere this answer might prevent accelerated hair loss, pointless stress and wasted hours.

Peace

[luke]

Hi, @MickPerez. We appreciate you taking the time to share the solution you found. It is a big help to others and will save somone from a “denvercoder9 scenario”. I do have a few more tips relating to deploys not updating the site.

You might also check to see if auto publishing is enabled or not. If you turn auto publishing on, then all new (successful) production branch deploys are automatically published.

Also, in a related thread, there is a “stop builds” setting (but that doesn’t seem to have been the issue here):

Stop or activate builds

That doesn’t affect publishing. It affects if the build itself will occur on not for new commits to the repo.

Finally, there is one last edge case for new deploys now working. When manual deploys are made with the Netlify CLI tool they won’t auto-publish either - unless you include the --prod option to indicate the deploy is a production deploy:

netlify deploy --prod

Thanks again for your follow-up and new topics are welcome anytime.