Don’t mess with the ListItemID managed property in SPO!

This post could also be known as the “Case of Microsoft and the HTTP/601 error” as it was certainly a mystery and took the combined efforts of myself and Microsoft to resolve the issue and trace it to the ListItemID managed metadata mapping!

I’ve recently been working on a document management solution for a client and due to the number of documents in each of the libraries, we were expecting to make heavy use of SharePoint’s in-line search capabilities in order to assist users in finding content.

If you’re not familiar with this functionality, it’s visible in classic lists and libraries in the form of a small search box that appears in the header of the list.

inline search box

Entering a search in this box causes a request to be sent to a site collection URL (/_layouts/15/inplview.aspx) that performs the search and updates the view with a filtered view of the list based on the search..

  • URL Before: …../Shared%20Documents/Forms/AllItems.aspx
  • URL After: ……../Shared%20Documents/Forms/AllItems.aspx#InplviewHashb258e3e…..

A similar experience happens in the new modern experience, but the search box is located in the top left of the window:-

You get both an in-line search in the search box (using a REST API call to /_api/search/query)

modern type ahead search

Additionally if you just enter a search and hit return, you get an updated list view, delivered via a call to ” /_api/web/GetList(@listUrl)/RenderListDataAsStream” which will update the list view (again without a postback, so a nice smooth experience.

modern in line search

Overall this is a great experience for the user once a list reaches a reasonably large number of items regardless of whether you’re in the classic or modern experience. Right up until it breaks!

So what happens when it breaks exactly? Well that depends if you’re in the classic or modern experience. If you’re in the classic experience nothing actually happens when you submit the search other than the bottom of the list view updating with a message regarding search that it always shows, but not actually changing what is shown in the view.

classic inline search failing

To the end user, it looks like the search has worked, but nothing has changed in the listview. If you have fiddler running however, you may see an error against the call to inplview.aspx with an HTTP/601

fiddler trace showing HTTP/601

And if we view the text of the response packet, we get a very unhelpful message back:-

Unable to render the data. If the problem persists, contact your web server administrator.

Correlation ID:bee4d79d-70a5-3000-d4e1-043daa279325

Which of course isn’t shown to the user as the page is expecting a list view rather than an error!

The modern experience is slightly better as it at least presents an error to the user that identifies that there is a problem although again it isn’t clear what the issue is. The type ahead search still works and presents our list items as per the previous example, but if we hit return to do an in-place search.. Boom, we get a flat tyre.. (literally!)

Modern experience flat tyre

But that error text does not provide a clear indication to the problem as we know that the view exists and we have permission to view it because we were just in it!

Again in Fiddler, we do see an error being returned by SharePoint Online, this time present an HTTP/400 error:-

Fiddler trace showing HTTP/400

Again the text in the packet received isn’t amazingly clear as to what the issue is either:-

{“error”:{“code”:”-2147024809, System.ArgumentException”,”message”:{“lang”:”en-US”,”value”:”Value does not fall within the expected range.”}}}

In the end, Microsoft turned up the logging settings on the client’s tenant and we performed some more tests and after analysing the logs, they identified what the issue was and it was a lot more simple than I expected! The search schema for the site collection had been amended and the managed property mapping for ListitemID updated to also include the ows_ID crawled property. Unfortunately when this was done, they did not tick the box that said honour the order, therefore all items had duplicate ID’s mapped into the managed property, causing the search issue.

ListItemID mapping

The issue was to remove the additional mapping of ows_ID and then triggering a reindex of the list content to return the search functionality to normal.

The moral of this story is don’t mess with the out of the box Managed Property mappings (especially ListItemID) unless you’ve tested it and know what it affects!


Leave a Reply

Your email address will not be published.


This site uses Akismet to reduce spam. Learn how your comment data is processed.