How the CSWP group cache can trick you

Hi,

This blog entry is a result of working with one of our customers on their Intranet solution in SharePoint Online. During this work, it became clear that the CSWP group cache was able not just to fool them but also the team that developed that cache (including yours truly). So, how did the CSWP group cache trick us all, and at the same time do exactly what it was designed to do?

Well, first, let's recap what it is supposed to do: The CSWP group cache is a cache living close to the UI that reduces calls to a back-end search server by caching results and returning the same results to all users in a configured group. The cache has an expiry policy of 15 minutes, meaning that results will never live for more than 15 minutes, but could live shorter in the cache.

So, in a typical development or testing setting, this is how you would go about:

  1. User adds some items to a list

  2. User grants a group permissions to those items

  3. User starts editing a page with CSWP on it

  4. User does some tests, both with and without cache.

    1. No results appear because they are not in the index yet.

    2. However, the cache is populated for the group, with an empty result set. This cache is valid for 15 minutes

  5. (after some time, random,typically 5-15 minutes, but could be less and could be hours) SPO continuous crawl picks up all changes and they are indexed

  6. User tests the web page continously

    1. User sees results in web page when running without cache (those indexed in 1 or already in the index)

    2. When turning on the cache option, web page returns 0 results, since it retrieves results from the cache

    3. User repeats the above until a actually returns results, but b does not

  7. User concludes that there is something wrong since the index now contains the items, and when configured with cache, 0 items are returned but without cache items are returned

Then, what happened? Why do you get no results back from the test page? What is wrong?

Well, it turns out that in step 4b, the cache, perhaps counterintuitively caches an empty result set. After the, whenever the group cache is asked for results for a query it will say "Yes, sure. I have the answer to that query. Here you go, there are no results for that query."

To get the expected behavior, you will need to

  1. (wait 15 minutes)

  2. Now cache has been timed out and page with cache on will return proper hits

How to avoid this?

Do the steps 1 and 2 in the opposite order, i.e. set the required permissions with a group first and then add items. Then, when an item is in the index it will be there with the correct group permissions and you can see the items both with and without using the group cache.

Cheers,

-Helge