The browser caching issue seems to have gotten worse

[kbeeveer46]

What type of issue is this?

Question

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

💥 SharePoint Framework

Target SharePoint environment

SharePoint Online

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

• Latest version of all browsers
• 1.17.1
• 16.16.0

Issue description

I was under the impression that after this ticket was completed that a lot of the caching issues would solved or have gotten better but it has only gotten worse for me. In fact, I barely had caching issues before but my co-workers did so I was always looking out for a solution.

SPFX webpart serving old files versions in Chrome #8803

Ever since that ticket was completed (maybe it's just a coincidence) I'm getting caching issues every time I push out a new version of our package to our QA SharePoint site. On top of the caching issues, I'm getting this generic error which I never got before. It goes away after 1 or 2 page refreshes. The only thing that has changed on my end around the same time is I renamed our solution from "xxx-client-side-solution" to just "xxx" but I didn't change the ID/guid.

I tried increasing the version number of the solution (which I never had to do before) but that didn't help. What's even worse is that I'll refresh the page and it'll be on the latest version, refresh it again and it'll go back to the old version, refresh it again and it's back to the new version, refresh it again and it might show the error above. It literally flips back and forth when refreshing the page several times (I'm not sure how it's even possible for it to go back to an old version after it has shown the latest version in the browser). I don't feel like that ever happened until a few weeks ago around the time of that ticket.

It's there something obvious I might be overlooking when packaging the solution for deployment other than making sure I'm running the clean command, using the --ship flags, and increasing the version number? Was there something I am supposed to add to my solution as the result of that ticket? I've been building this solution for 2 years without any caching issues (or ever getting that error above) up until about 2-3 weeks ago.

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

[AJIXuMuK]

@kbeeveer46 - could you please check the Network tab and send information about headers (similarly to what has been sent in the issue you're referencing).
Also please check what scrips are failing to load.

[kbeverforden]

@AJIXuMuK I just did a quick test and increased the version number from 4.1.1.0 to 4.1.2.0 and uploaded it to our test site. I was not able to replicate the issue at first. I went through ~10 different pages all with a single web part on them and they showed the latest version # on them. Then I tried 5 minutes later and was able to replicate the issue in both Edge and Firefox on 2 different pages/web parts and they both show different errors. I pasted the screen shots below.

Let me know if you need more details about these 2 web parts. I looked in the dist folder and the guids don't match the guids on the end of these .js files so I'm assuming it's trying to use an old version and the mime type and cors errors are "fallback" errors and red herrings.

Edge:

Firefox:

[kbeverforden]

@AJIXuMuK Now that it has been an hour I am not able to replicate the error or see any caching issues on several browsers on a Windows and MacOS machine. It appears it's just happening within a certain amount of time after uploading the new version. We will just have to move our releases to later at night. I just wanted to bring it to your attention because I had never experienced this in the 2 years I've been developing this SPFx solution. There may have been random caching issues here and there but never this error and never on every single new version upload.

[AJIXuMuK]

@kbeeveer46 - it might be related to how the CDN propagation works. Maybe there is an interval when the assets are being updated.
We will still check if there is something we can do here.
But good to hear the issue is fixed for you.

[demyren]

@kbeverforden If/when it happens again, can you find your file in one of the "Site-[id]" cache storages? I would like to see what got returned from server and cached by the service worker on the initial requests after you deployed a new version. Thank you!

[kbeverforden]

@demyren I've never been in that caches area so I don't know what the important parts are to screen shot. There were multiple site-id's but only one had the web part that failed. I filtered the list down to that web part and ordered by cache time. The one that is highlighted blue is the one in my dist folder (are those 4 old versions below it supposed to be there?). I also took a screen shot of the console (this time it only had 1 error and doesn't tell me which version of the web part it tried to load). Let me know what else you need screen shots of.

As someone looking at this for the first time, the only thing that stood out to me was the "0" for content length but it's showing the contents of the highlighted web part in the bottom preview and there's content to it.

[kbeverforden]

@demyren I don't know if it matters, but we're using a site collection catalog on a site called "ClientPortalQA" which is where we upload the package to for our QA team to test and then it gets uploaded to our tenant app catalog at the end of our sprints. So the same package is on multiple app catalogs at any given time. I think one of the entries in that list above that doesn't have "ClientPortalQA" in it is from the tenant but I'm not sure.

After looking at those 2 screen shots closer, the guid in the error in the dev console that starts with "02f..." matches the guid in the web part I selected in blue. The preview at the bottom has the same guid. EDIT: Nvm, all of them that were cached throughout the day have that same guid because it's the quid of the web part. I was trying to find a link between the dev console error and an entry in the site-id.

Here is the contents of the Headers tab in case it helps

[kbeverforden]

@demyren Sorry for another comment. I just don't want anyone wasting time spinning their wheels based of something I possibly did on my end so I want to provide any insight I can think of. The screen shot of the dev console error where it has 1.0.0 on the end of the file name reminded me that we never increase the version number in package.json. We just never knew to and everything always worked fine the past 2 years so we kept it that way. Could that be causing any issues since 1.0.0 doesn't match 4.1.3.0 in package-solution.json?