View all articles by this author
One of the most powerful features of SharePoint is the Search Rest API. It allows us to obtain, filter and personalize information that’s useful to a user and allows us to create pages of content of interest for them.
Well sometimes, despite the incredible effort that Microsoft makes to maintain the infrastructure, something goes wrong. Which is what happened a few weeks ago.
Atlas provides a series of content pages that contain search-based webparts and show information classified by type, news, events, knowledge pages, search pages to find users, documents, etc. Suddenly we began to notice how, in some tenants, the user search page initially, and later other pages, were displaying the wrong content. The proper filters weren’t being applied.
Our web parts use the SharePoint Rest API for search, running queries that are defined as Result Sources at tenant level. (Here’s an overview of the SharePoint Search REST API.)
To understand what was happening, we had to look for clues in the traces of the requests that were made to the servers.
For this, we could use a tool like Fiddler, or open the Developer tools of the browser (F12) and search the Network tab until we found a GET request to a "query" or POST "postquery" endpoint.
What we were looking for was which query SharePoint was actually interpreting.
From our experience, when a web part returns too many results in a search request, it’s because the query string is not well defined. But that wasn’t possible in this case – nobody had touched the code and suddenly it stopped working.
Each time we ran a query, the API response looked like this:
As you can see, there’s a property in the Json reply, ‘QueryModification’, that tells us the query that SharePoint is actually running.
Without going into much detail about how the Search API works, we found that, despite querying the Result Source by name (Local People Results), when we inspected the response, QueryModification, it had an incorrect value. This didn’t happen however, if we made the query with the Source ID. That helped us to understand that the issue was with Search, not our web part itself.
From there, we put aside our code, and directly began to make direct requests to the SharePoint API through the browser (we were also using the very useful Search Query Tool).
Copy-pasting this into the browser and replacing the [tenantName] and [sourceName] help you to see if SharePoint finds your Result source from the Tenant and is working fine.
https://[tenantName].sharepoint.com/_api/search/query?querytext=%27*%27&rowlimit=30&selectproperties=%27Path%2cUrl%2cTitle%2cAuthor%2cWrite%2cServerRedirectedEmbedURL%2cWorkId%27&clienttype=%27WebService%27&properties=%27SourceLevel:SPSiteSubscription,SourceName:[sourceName]%27
The reply to that query should be something very similar to the previous JSON but in XML, and it will work for OOB or custom result sources.
All these tests served to isolate the problem: we detected that there was an issue with the Search API and we were able to open a ticket with Microsoft giving them a clearer view of the problem and helping in the diagnosis and resolution times.
Sometimes the problem can be on our side, and knowing how to troubleshoot search issues in SharePoint can save us a lot of time.
