SPFX webpart serving old files versions in Chrome

[johnnycardy]

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

💥 SharePoint Framework

Developer environment

None

What browser(s) / client(s) have you tested

• 💥 Internet Explorer
• 💥 Microsoft Edge
• 💥 Google Chrome
• 💥 FireFox
• 💥 Safari
• mobile (iOS/iPadOS)
• mobile (Android)
• not applicable
• other (enter in the "Additional environment details" area below)

Additional environment details

No response

Describe the bug / error

This bug seems to have resurfaced: #7664

A previous version of an azure CDN-loaded SPFx script is being used.

When I do a hard refresh (Ctrl+F5), it loads the latest script.
When I do a normal refresh, it loads a cached script.

I can see this on my dev tenant and also one live customer tenant has reported it.

Reloading with Ctrl+F5:

Loading normally:

Steps to reproduce

• Update SPFx scripts in Azure CDN
• Purge azure CDN cache
• Perform browser refresh
• Old version of script is shown even after hard refresh is previously performed.

Expected behavior

After a hard refresh is performed, the new script should be persisted in the browser cache.

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[AJIXuMuK]

@johnnycardy - could you please check if ?sw=bypass in the url fixes the issue?
Another option to check the same is to open dev tools -> Application -> Service Workers -> Bypass for network

[johnnycardy]

Yes, that has the same effect as ctrl+F5 - forces the latest version to be used.

Then when reloading the page again without the URL parameter, the old version is loaded.

[demyren]

Hi @johnnycardy, do you know if possibly the js file was initially deployed and used without a Cache-Control header? I don't see a such header in your second screen shot of the normal F5 page load, which makes me think that the service worker initially cached a version of the file that did not specify Cache-Control. If the headers were added later, it may be that the service worker doesn't get the new version because it still has the old version cached without headers.

You can see the cached version of your file in F12->Application->Cache Storage in one of the storages named Site-[id]. Does it have a cache control there? If you delete this file, does it start honoring the latest version then?
Thank you!

[johnnycardy]

@demyren yeah that's correct, it originally had no Cache-Control header and that is indeed what is cached by the service worker, and if I delete that then I expect it will pick up the latest version, but the issue unfortunately is that I can't do this for the users who currently have cached version in the browser.

[demyren]

@johnnycardy I see, thank you for confirming. Unfortunately, we don't have any simple means of force-clearing the cache storage without user intervention.
We are currently rolling out a change that will do this when the user explicitly signs out of SharePoint. If you are a First Release tenant, you likely have this new functionality. Then, if it is an option to ask the users to sign out and back in, that will solve the problem.

Alternatively, we could possibly add some means of force-clearing the cache storage in the service worker as well. For instance, we could start supporting a query string for deleting the cache storage.

Otherwise, if you have any other means of programmatically deleting the cached file or cache storage for the affected users that could be an option too. Do you think any of these options would work?

[kbeeveer46]

@demyren I'm not the person you responded to but I have a similar issue regarding caching that I've been trying to solve on my own but I figured I asked in this thread. We have a SPFx project that has 20+ webparts in it. When we release a new version we increase the version number in package-solution and overwrite the existing sppkg file in the tenant catalog. I have never experienced this issue, but several of my team members are served the old version until they manually press CTRL+F5. I've read online that increasing the version number should automatically serve the latest version to users but that doesn't seem to be the case. This issue has happened 3 or 4 times now. Is there anything I can add to the code so that it always pulls the latest version or is that something controlled in the user's browser?

[johnnycardy]

@demyren thanks for outlining the options. It looks like I will need to deploy a new package pointing to a new URL with correct caching headers.

Just to be clear, the serviceworker cache will adhere to the Cache-Control header?

[tarcisiopqdt]

same problem here :(
has anyone found any solution?

[demyren]

@kbeeveer46, @johnnycardy and @tarcisiopqdt,

Thank you all for commenting on this thread and letting us know. @johnnycardy, the service worker does adhere to the Cache-Control header. However, if the file was initially published without a Cache-Control header, it may have gotten cached indefinitely, preventing the file from getting updated. CTRL+F5 forces files to get re-fetched, however has no effect on service worker cache storage.
If this is the problem, you can verify it by viewing your file's cache headers in the cache storage from F12->Application->Cache Storage in one of the storages named Site-[id].

I expect that if we once clear the cache storage where we are seeing this problem, the problem should never come back. I do hear you though, that it is not feasible to do this for all users that may be experiencing this problem.

We are rolling out a change currently that clears the cache storage when the user signs out, so that can be one workaround.
That said, we will look into means of clearing files from the cache storage, to address situations where files got inadvertently cached indefinitely, even though they later introduced cache headers.
I will update this thread soon, when we can provide some automatic resolution to this problem. Thank you!

[demyren]

@kbeeveer46, @johnnycardy and @tarcisiopqdt,

I wanted to circle back quickly and let you know that we are making a change that will start treating JavaScript files without a Cache-Control header, as not cacheable.

We will implement this both into caching of new files to prevent them from caching without cache headers, and more importantly also into expiration evaluation, meaning as we are about to serve a cached file, we will first validate that it has cache headers. If no Cache-Control header, we will expire it immediately and fetch the new version from network.

This change does mean that it will be more important to ensure proper Cache-Control is given to script files, or they may not be cacheable. That said, after learning about the problems you have with our current strategy which is to treat files without Cache-Control as indefinitely cacheable, this seems like the right solution.

We expect to complete deployment of this change to Production within 2 weeks from today. Once it has been fully rolled out, I will update the thread again. Then, this should mean that once your users get that new service worker installed, even if they have files inadvertently cached indefinitely, those will expire then and new versions will be fetched from network.

Thank you for reporting these issues. We want to get this right, and we will actively listen the feedback from the community that can help improve our product.

CC @AJIXuMuK