Currently the site hash is being generated when it is first requested and then saved into config. It is not a good practice to do unsolicited writes to the configuration (or even to the database in general). We have had some problems with this recently while preparing the update of a large distribution to Drupal 8.5.0:
site_hash is stored as an empty string in the exported config. On initial deployment to production this works fine: a site hash is generated and subsequently used. If an update is deployed to the site, the site_hash becomes empty again, causing a new site hash to be generated, which differs from the original one.
I did some research and it seems this approach has originated many years ago in the original version of the ApacheSolr module in Drupal 5 (ref. apachesolr_site_hash()).
The solution is to generate the site hash when the module is installed, instead of on first use.
Note that it can be debated if this setting even belongs in config, or should be moved to state, but that is already being discussed in #2864967: Fix multisite search/multiple indexes on one core, tho it might break spell checking, autocomplete and suggesters → . This issue is only about not writing config on an arbitrary GET request.
Marking this as a minor bug since it has limited impact for most websites.
Fixed
2.0
Code
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
If anyone else finds this issue trying to figure out why they can't set their site hash in config, here's the answer on how to set and get your site hash now that it's in state:
https://acquia.my.site.com/s/article/360045953834-The-importance-of-uniq...
drush sget search_api_solr.site_hash