Which can lead to secondaries believing that collection is still sharded.

setup:

• collection test.user is sharded
• 1 shard, current primary: nodeA
• shard's nodeB never heard about test.user, so it never had any catalog cache entries.

1. _configsvrDrop deletes all config.chunks and config.collections.
2. nodeA steps down, and nodeB becomes new primary.
3. _configsvrDrop sends setShardVersion (0,0) to all shards. Since nodeB never had any entries, set shard version was a no-op.
4. If secondary read with shard version comes to nodeA, it will try to ask nodeB (the primary) to refresh with _flushRoutingTableCacheUpdates.
5. nodeB will end up calling getDatabase and load all sharded collections under that database, but since test.user is already dropped, it will be skipped.
6. So nodeB will end up returning early without asking the CatalogCacheLoader to reload. The consequence is that since the catalog cache loader did not perform the reload, the config.cache collections for test.user will remain untouched.
7. nodeA gets ok response from _flushRoutingTableCacheUpdates, and then tries to check the version via reading config.cache.chunks, and will find out that there are still documents and erroneously believe that collection is still sharded.