Config server startup will initialize its sharding state if a shard identity document is found locally. This triggers loading cluster settings from the config server, including the cluster identity document, which is assumed to always be available if the shard identity was found, since it is always inserted earlier when the first config primary steps up. This logic runs before replication recovery, so if the config server restarts after a failed initial sync that only copied the shard identity document, there may be no cluster identity, which triggers an infinite retry loop looking for that document, blocking startup.