The CatalogCache executor pool is limited to 6 threads. CollectionCache, DatabaseCache, and IndexCache share this executor.

1. In the config shard, 6 threads are refreshing the CollectionCache for different namespaces, occupying all threads in the pool.
2. The refresh eventually reaches out to the config server through ConfigServerCatalogCacheLoader, and runs an aggregation on it.
3. The aggregation uses (readPreference: nearest).
4. The aggregation doesn't use timeout when the node itself is config server.
5. Targeting returns this node.
6. Execution of the aggregation, which contains a $unionWith, and preparing the subpipeline involves routing.
7. This schedules a job in the CatalogCache thread pool, to fetch the routing information for "config" database.
8. And waits for it to complete, which never does because no threads in the pool will ever be freed due to the circular dependency.