Not bumping the collection version is a problem for scenarios like:

1. Creation of Collection A
2. Creation of Collection B
3. Rename of A to B, dropping target collection.

Assuming that a router saw A and B before the rename, if this router tries to refresh its routing information about B after the rename, this refresh will hang forever.

The underlying problem is that since we didn't bump the collection version, the router thinks that the routing info it has about B is more recent than the one it gets from the config server.

Solution:

We have to bump the collection version. The Collection Version of B after the rename should be newer than the one we had for B before the rename.

• If we take the conservative approach, this would imply modifying all entries in config.chunks for this collection + its entry on config.collections. Doing that should be enough and it will behave similarly to what we do in refineShardKey. As a drawback we will have to update all chunks associated to the Collection which is something we tried to avoid as much as possible: that's why we replaced the namespaces by uuids, to avoid having to update all chunks.
• The other approach tries to avoid having to update all docs associated to the collection on config.chunks. Since the replacement of NSS by UUID on config.chunks, we believe that there is no reason to have the epoch and the timestamp on config.chunks. Thus, if we manage to get rid of those, the rename will only have to update config.collections. In order to support backward/forward compatibility we will have to do some minor modifications to the setFCV cmd.