Right now, the creation of the internal config.system.sessions collection runs on the first shard in the cluster rather than on the config server. As a result, we may not be installing the filtering metadata authoritatively on the config server, even though it is the DBPrimary for that collection. This could lead to incorrect routing behavior: a shard may target config.system.sessions as if it were unsharded, while the config server may interpret the absence of filtering metadata as meaning that the collection is unsharded, which is not the case.