Undocumented breaking change in Episerver.Find 13.2.0 affecting on-premise Find installations

In March 2019 Episerver released Episerver Find 13.2.0, with a lot of bug fixes, and five new features. It all looked quite harmless.

After upgrading a website with an on-premise Find cluster, in early August, some queries failed. Because my main reason for the upgrade was to check if Episerver had implemented the new navigation system (introduced in Episerver.CMS.UI 11.20.1), which it turned out they had not, I rolled back. If there actually was a problem with the update, I could just wait a couple of months and leave it to others to report the bugs.

So, when Episerver now released Episerver.Find 13.2.5 with the new navigation system, I wanted to upgrade. Yet again I was greeted with failing queries.

Some excerpts from the exceptions returned:

The remote server returned an error: (400) Bad Request.

SearchPhaseExecutionException[Failed to execute phase [query], all shards failed; shardFailures...

Parse Failure [Failed to parse source...

...nested: ElasticSearchIllegalArgumentException[sort option [unmapped_type] not supported]; }]"

The last line mentioning [unmapped_type] is the important one. It turns out that Episerver introduced a breaking change in 13.2.0 that was silently «fixed» in 13.2.4 by adding the undocumented configuration parameter ignore_unmapped.

After contacting Episerver support, they have today added some more information to the bug FIND-5988.

This was fixed in Find 13.2.4 by adding a configuration option to enable legacy sorting as follows.

To enable legacy sorting, add useLegacySorting=true to your episerver.find config element.
<episerver.find serviceurl="" useLegacySorting="true" ...>

Using DotPeek I can see that under the hood, Episerver adds ignore_unmapped = true to the search query when we set useLegacySorting = true. More information in the elastic search documentation.

Adding useLegacySorting = true fixed my failing queries.