SharePoint Caching Problems with Lists

[robertchamplin]

I have been having odd behaviors with regard to configuring SharePoint lists that started occurring the last 2 days:

(1) When adding list columns they do not show up until I refresh the page

(2) When editing the list name, it reverts to the old list name after a page refresh

(3) When editing list item layout (JSON code) it saves and displays correctly until I refresh the list, at which point the code is deleted and the layout returns to default

(4) When editing list column details some changes revert to the previous value after a page refresh (column names, choice elements, and other settings).

(5) Some lists show me as only having read-only access when I am clearly on the "edit" list

I am having these problems with multiple lists across multiple SharePoint sites.  All of the issues are fixed by working in "private" browser mode; some are fixed temporarily by clearing the cache.  Does anyone have any ideas on a fix?  Incognito mode is fine, but annoying to have to go through all of our company's verification steps every time I go in to make an edit.

Update: I did all my JSON changes in private mode which worked for me, but any time anyone opens a list item it deletes my code and reverts back to the unformatted version.  Any help is appreciated.

Office 365/SharePoint Online, MS Edge browser Version 94.0.992.38 (Official build) (64-bit)

Thank you in advance!

[#2]

Hello,
similar issue for us. (office 365 / sharepoint online)
test with differents uptodate browsers (edge chromium, chrome, firefox), with differents users.
Always need to clear cache (cookies and data site) or use incognito mode.
the pb is when users modify 1 line, all data in this line are blank and then auto save clear all data in this line.
all users are not impacted, but they are more every day.

Thank you in advance!

[#3]

Hi, wanted to add that we're seeing the same issues and solutions. Some users are getting errors of lists not showing data. They change browsers and it works for a while but then the same errors appear. It is solved by clearing cache or working incognito. I am not getting the errors, and the only difference we can see is that I'm running Windows 11.

[#4]

At least we are not the only ones.  When you say it is "solved" by clearing the cache, do you mean permanently?  Whenever I clear the cache it loads correctly the next time, but then the problems return when they navigate away from and back to the list (including the issue of deleting my list item JSON formatting code).

[#5]

At my company we have something similar for some users. And this is working only when the browser cache is cleared but only once you are working with the list.
If you go to another website and jump back in the list the issue comes back. So basically you will have to close the browser each and every time you go out of the list. INSANE!

Our issue is with with the view/edit form of the standard SharePoint list. If you double click on a selected item, the standard view/edit form is blank and no data is showing. Even if you were to click button: EDIT ALL in the view/edit form, the data wouldn't appear for that particular item.
Additionally, the view-formatting JSON is not saved as well if you were to paste it in.
The thing is that not all of the lists are affected by this issue.

However, if you were to copy the link to the item and paste the link into another browser tab the data is shown in the full screen form view, with the view-formatting JSON applied correctly.
Some users say that this issue occurred after a Windows Update. Not sure if that is the main reason.

[#6]

I, too, had a few Microsoft Lists users encounter the exact same behavior beginning around the same time. Incognito/InPrivate/Private windows seem to circumvent the caching issue, but that's not a solution, just a workaround. I opened a ticket with Microsoft (#28088946) back on 10/25 which resulted in a response of essentially, "There must've been some change rolled out to Sharepoint/Lists that caused this caching issue. I'll report it and expect it to be resolved in the near future, and until then just use Incognito mode." I was excited to find this thread of others experiencing the exact behavior we were seeing, so at least I know the issue is bigger than just my little operation...

Just today (12/3), for the coworker who's been reporting this issue over the past week and clearing her Chrome browser cache doesn't seem to be a lasting solution, I uninstalled Microsoft Lists PWA (installed under Chrome previously) and had her sign into Edge and open Lists, then installed the PWA under Edge instead. Hoping for a longer-lasting period of proper functionality before the caching issue starts happening in Lists PWA/Edge. Chrome is still her default browser, so at this point she's ONLY using the Edge engine for the Lists operations...

[#7]

We too are experiencing the same exact issues. We have been instructing users to go back to the Classic UI when possible and building custom solutions that pull from the API when not, as there seems to be no rush from Microsoft on trying to fix this issue.

[#8]

@robertchamplin   I did just re-report this issue to Microsoft (via ticket #28786964), and the tech informed me that this issue has been reported by others, they are aware of the issue and working toward a resolution.  They did tie my tenant to this issue, so I should be seeing updates related to this issue in our Admin Message Center as well (I just got off the phone so it's too early to expect to see anything yet).

They did, however, acknowledge that there was an issue.

[#9]

@CJohnston71 Thanks for the update and for running this to ground!

[#10]

I'm not holding my breath on this; hoping for some successful resolution. The link to THIS thread has also been provided (at the Microsoft tech's request) and attached to my ticket.

[#11 · Accepted solution]

Hi group, I did some digging on this and believe I have found the issue for our tenant.

The OneDrive client appears to be syncing Lists from SharePoint Online (et. al) by default.  To verify this is what is happening, you can perform the following steps:

1. Open Dev Tools on Chrome (F12)
2. Navigate to "Network"
3. Select "Fetch/XHR" as type
4. Enter "RenderListDataAsStream" as a filter
5. Attempt to sort a list that is cached

The results should show "localhost", "::1", or an equivalent loopback address under the "Remote Address" column.

You can then use resmon, netstat or Get-NetTCPConnection/Get-Process to find the IM of the process name and ID of the port being used for these local XHR requests to the RenderListDataAsStream endpoint.  In my scenario, it was port 42050 (probably randomized), which was shown in use by the Microsoft.SharePoint.exe application, located under \AppData\Local\Microsoft\OneDrive\<version number>.

If you see this behavior, you can attempt to mitigate the caching by:

1. Setting 

   [HKLM\SOFTWARE\Policies\Microsoft\OneDrive] "DisableNucleusSync" = "dword:1"

   (per MS Docs - Use Group Policy to control Lists sync settings )
2. Rebooting machine, or force closing the task with IM of "Microsoft.SharePoint.exe".
3. Reloading the list page (may need to force-refresh).

This appears to be working on our test machines (all Modern UI queries are forced to use the SPO servers instead of OD), but I'm not entirely sure of the effect this setting could have in regards to SP, OneDrive, Teams, etc - so it should probably be used with caution.

Hopefully this helps your tenants as well.  Good luck!

[#12]

Good find - and the timing of that "feature" matches up with when the problem appeared. Thanks for digging!

[#13]

Hi, did they give you a resolution on this? We're experiencing the same issues but lately, MS Support has unable to resolve any of the issues we've reported

[#14]

No, MS was quick to say it was something that they'll report to development, and they expect the issue to "go away" with updates. Did you try the suggestion proposed by jnlce on 1/13? I've got just a small handful of users impacted by this, and they've just sort of been quietly dealing with it. I haven't tested out jnlce's suggestions yet, but that did seem like potentially the best find so far.

[#15]

Jnlce's suggestion is the best so far - it only addresses the problem for individual machines, and only if your security settings allow it.

[#16]

Ah okay, seems like it's been going on for awhile now and MS hasn't been able to address. I will look into jnlce's suggestions. will have to do this for more than one user 😞

[#17]

Did you try any of the fixes and if so, did they work?

[#18]

@Matthew Carter So far changing the List Settings - > Advanced Settings -> Set Offline Client Availability to 'No' seems to work.
I also had a ticket with MS Support for this and they provided the same steps that @jnlce mentioned in this thread. I added the DisableNucleusSync and set dword:1 as specified here: Lists sync policies - SharePoint in Microsoft 365 | Microsoft Docs  Make sure to reboot after making the change.  The change will have to get pushed out to all users though.  Both solutions fixed other issues we've been having as well, and so far, no caching problems after the fix was applied.  

[#19]

I am unfortunately not in a position to push a change like that out to everyone's PC to fix it, and it doesn't help me to only fix it on my PC because everyone else still overwrites the formatting when they access the list, so I've had to push it to the back burner and move on.

[#20]

For now, maybe try changing List Settings - > Advanced Settings -> Set Offline Client Availability to 'No' to the list you’re having issues with. This way, you don’t have to push out any changes to users. This appears to be working for us so far.