The ClusterIdentityLoader caches the clusterId document from the config.version collection on the config server. During startup, a shard with a shard identity document will load the clusterId from the config server. If no document can be found, startup will retry indefinitely (via this logic). To work around an issue where the config server can transiently have a shard identity but not a clusterId because of a failed initial sync which blocks startup, the config server skips loading the clusterId at startup as of SERVER-78000, instead only loading it on the first step up to primary.

Currently shards don't use the clusterId after loading it, not even to validate it matches the clusterId in the shard identity document. Only the config server uses it when creating the shard identity document for a newly added shard. SERVER-23769 proposed validating the clusterId, but was closed as "won't do."

This ticket is to track reevaluating how we use the ClusterIdentityLoader so it's more useful on shards.