Last week we had an issue that caused Sitecore to be unable to connect to SolrCloud. Therefore, the container Readiness healthchecks failed, resulting in loss of service. This has been fixed.

During the incident, we noticed in the telemetry that we were seeing Healthcheck Failures for most of the search indexes. However, not all – master, web, and preview were all missing. This was puzzling. One commonality between the missing checks was that all missing indexes used Switch on Rebuild functionality to ensure service, even during a full index rebuild.

It seems that the Healthchecks for SOLR are created by the Sitecore.ContentSearch.SolrProvider.DependencyInjection.ContentSearchServicesConfigurator (patched into config by Sitecore.ContentSearch.Solr.DefaultIndexConfiguration.config). Looking within that class I found a static method “GetSolrCoreNames“. This uses an XPATH query of the Site’s configuration to find the Solr core names. Specifically, it looks for the <param desc=”core”> element.

However, if you are using SOLRCloud, and have configured switch on rebuilding of your indexes, as per https://doc.sitecore.com/xp/en/developers/100/platform-administration-and-architecture/switch-solr-indexes.html, then the index does not have a “core” parameter. Rather, it has a “mainalias” and “rebuildalias“.

Therefore, the “GetSolrCoreNames” method will not find SolrCloud indexes where switching has been configured as per Sitecore’s documentation. Non-switching indexes work correctly, and Healthcheck failures are logged correctly.

I’ve raised this with Sitecore, but to fix it myself, I would look to reimplement the ContentSearchServicesConfigurator with a change to also search for the mainalias. (It’s not a big class)

Update: I had a response from Sitecore support. It’s a known bug, reference number 604557. They don’t think there’s an easy work around. I actually think there is; reimplement the configurator.