The curious case of what happened to my Indexing Manager

I’ve spent the last week or so working on the config changes necessary to migrate a client site running Sitecore v8.1 from using Lucene to Solr for its search infrastructure. I’ve not worked much with Solr before, so this has been a good opportunity for me to learn about how it works and how it gets configured. But when I deployed my changes from my local development environment to a central testing server I discovered some odd behavior which Google didn’t help with. So, for the good of search indexes everywhere, here’s what happened…

The issue

The first thing I spotted was this – a component that should have had search results displayed was showing nothing:

Looking in the Sitecore logs I found no errors being reported, and checking the Solr instance that the site was using, this was up and running.

My immediate thought was “perhaps I need to re-build an index”, so I opened up Sitecore’s Control Panel and clicked “Indexing Manager”. And waited. Nothing happened. So I clicked a bit more, and still nothing happened. No grey “this is a modal dialog” overlay appeared and no dialog popped up. Clicking “Generate the Solr Schema.xml file” had the same issue, but other links such as “License details” worked fine.

After the usual “turn it on and off again” flailing, I tried checking the Sitecore logs – nothing at all. So I opened up my browser’s developer tools console, and checked for errors there. Nothing again. The network trace showed that clicking the Indexing Manager link generated a valid request:

But what was interesting was the response to that request was empty. However, when you watched that request for a working link on the page, the response body included a chunk of Json data like this:

{
  "commands":[{
    "command":"Eval",
    "value":"scForm.showModalDialog('/sitecore/shell/Applications/About?mo=popup', '_blank', 'getBestDialogSize:true;header:License Details');"
  }]
}

That made me start to wonder about whether I’d made a configuration mistake – so I spent a bit of time with a diff tool, looking at what was different between my (working) local developer site and the (broken) QA site…

The resolution

It turned out that the answer was trivially simple: The one significant difference between the two sites was that the broken site had no copy of Sitecore.ContentSearch.config. As soon as I restored this file to the server, everything started working correctly again.

Investigating what had happened, it turned out this was entirely my fault. As part of my deployment process for the changes I’d been working on I’d written a PowerShell script to remove a set of old custom config files that were focused on Lucene indexes. The site’s standard automated deployment process would not have removed these, so I automated the tedious manual task. But a copy/paste error in my script meant that it accidentally removed the Sitecore.ContentSearch.config along with these custom files. And I’d not spotted that in my local tests before I did a deployment.

So the moral of this story is twofold:

  1. If you automate, remember to test your scripts properly before using them in anger.
    I’d tested my script by running it against a specially created folder containing only the files I expected to be removed. Hence I never saw the bug in the script which caused this problem.
  2. If expected configutation is missing, raising errors or logging something can really help your user’s diagnose what they’ve done wrong…
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

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