What causes Examine to rebuild indexes?

Questions
1

Hello! I am running Umbraco as a Docker container. I have a volume mounted at /opt/www/umbraco/data and thus the TEMP directory for instance is preserved between restarts and, hopefully, re-creation of the container.

However… on restarts everything is fine, but on re-creation Examine always rebuilds its indexes. Which means it loads all content items in memory, which is not nice, considering that Hybrid Cache is doing wonders at lazy-loading things.

Since everything is fine on restart but not on re-creation, I am suspecting something happening with machine keys… are Examine indexes “signed” or in any way related to the exact machine that is creating them? What is the logic used by Examine to determine whether what it finds on disk is usable, or needs to be rebuilt?

2

Hi @zpqrtbnk

Can you see anything in the logs after a re-creation that may indicate why it is rebuilding the indexes? If not, it may be worth dropping the Serilog levels to Debug:

"Serilog": {
  "MinimumLevel": {
    "Override": {
      "Examine": "Debug",
      "Umbraco.Cms.Infrastructure.Examine": "Debug",
      "Umbraco.Cms.Infrastructure.HostedServices": "Debug"
    }
  }
}

The rebuild logic is in ExamineIndexRebuilder.ShouldRebuild:

return !index.IndexExists() || (index is IIndexStats stats && stats.GetDocumentCount() == 0);

IndexExists() ultimately checks DirectoryReader.IndexExists(GetLuceneDirectory()), which is just a check for files on the disk. So either the directory is empty or the index has zero items.

Given it’s fine on restart but not on re-creation, I’d check where GetLuceneDirectory() is actually resolving to. If Umbraco:CMS:Hosting:LocalTempStorageLocation is EnvironmentTemp the indexes are in the temp path, not /opt/www/umbraco/data, so they’d survive a restart but not a re-creation.

Justin

3

OK, I have asked Claude’s opinion on the topic. Says that indexes are rebuilt anytime the boot is classified as a cold boot which is what happens. Says it’s a cold boot based upon “last synced cache instruction ID” that is keyed on Environment.MachineName. Says since hostname keeps changing in Docker, it’s always a cold boot. Recommends setting the hostname when starting the container.

So… updated my Docker Compose config with an hostname. Now going to run more tests and figure out whether that solves the problem. Will report!

4

OK, that did it. Just redeployed and indexes were not rebuilt. Case closed.