Forum Discussion

robertchamplin's avatar
robertchamplin
Copper Contributor
Oct 21, 2021

SharePoint Caching Problems with Lists

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!

  • 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!

  • MiloszW's avatar
    MiloszW
    Copper Contributor

    In my organization, users are facing the same problem. Disabling offline accessibility does not solve the problem at all. Only clearing Sharepoint's cookies helps, but this only works for one use of the list.

    • jonas_jansen's avatar
      jonas_jansen
      Copper Contributor

      MiloszWI faced the same Problem with two users. Luckily it is fixed now.

       

      I deleted the following folder: C:\Users\Username\AppData\Local\Microsoft\OneDrive\ListSync. To accomplish this you have to first stop the Task for OneDrive and Sharepoint via Taskmanager.

       

      After that, it all worked as intended. Hope this helps!

       

       

  • GeorgV's avatar
    GeorgV
    Brass Contributor

    I have to click refresh several times to be sure the page is on the newest version. Even if there is a reason why the page is not dynamically updating, why is there not an element which informs me that changes are available and I should refresh. A simple hash behind it or whatever would be enough.

    This uncertainty lowers acceptance of lists immensely and I regretting to have introduced it. 

  • jnlce's avatar
    jnlce
    Brass Contributor

    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!

    • robertchamplin's avatar
      robertchamplin
      Copper Contributor
      Good find - and the timing of that "feature" matches up with when the problem appeared. Thanks for digging!
  • CJohnston71's avatar
    CJohnston71
    Brass Contributor

    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.

    • pdfrig's avatar
      pdfrig
      Brass Contributor
      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
      • CJohnston71's avatar
        CJohnston71
        Brass Contributor
        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.
      • CJohnston71's avatar
        CJohnston71
        Brass Contributor
        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.
  • jnlce's avatar
    jnlce
    Brass Contributor
    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.
  • CJohnston71's avatar
    CJohnston71
    Brass Contributor
    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...
  • Phil13590's avatar
    Phil13590
    Copper Contributor
    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!
    • extrawurst's avatar
      extrawurst
      Copper Contributor
      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.
      • robertchamplin's avatar
        robertchamplin
        Copper Contributor

        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).

Resources