Changes to renameCollection are limited to what is necessary to remain on parity with 3.6, which is:

• only support renaming unsharded collections
• if the rename reports failure, the collection data must be reachable through mongos under either the original name or new name

_configsvrRenameCollection logic

1. ScopedDistLock dbLock(dbName)
2. ScopedDistLock originalCollLock(originalCollName)
3. ScopedDistLock newCollLock(newCollName)
4. Insert an entry into config.collections with the new name; all other fields copied from the entry for the original name
5. Insert an entry into config.chunks with the new name; all other fields copied from the (single, since we’re only supporting renaming unsharded) chunk for the original name
6. Send renameCollection to the shard that owns the (only) chunk
7. Remove the original name’s entry from config.chunks
8. Remove the original name’s entry for config.collections

Note that if the rename fails before step 6, the collection data is reachable under the original name somewhere in step 6, it’s reachable under either the original or new name after step 6, it’s reachable under the new name which satisfies our requirement that the collection data remains reachable, no matter where the rename fails.