On a secondary, there are many steps between parsing a create oplog entry and creating the replicated collection in the DurableCatalog. 

The secondary path manipulates the provided information each step. For example - the create entry's idIndex(1, 2)  and uuid are encoded in different forms across the code path. 

By reducing the number of steps from oplog entry to succesful replication of a collection, it will be easier for developers to modify the oplog entry structure and replicate new information. 

This is particularly relevant as we try to replicate catalog information from the primary to the secondary.
 
Today's code flow for replicated collection creation
Primary

• Writes createCollection oplog entry in OpObserverImpl::onCreateCollection()

 
Secondary

• Start point for create oplog parsing: kOpsMap create (oplog.cpp)
• • 3 separate conditions that all call `createCollectionForApplyOps()`, dependent on idIndex 
• createCollectionForApplyOps(opCtx, dbName, optional<UUID> ui, BSONObj cmdObj, bool allowRenameOutOfTheWay, optional<BSONObj> idIndex)
  • UUID conflict handling - renaming collections out of the way if collections already exists
  • Encodes 'ui' into the into a new copy of the `cmdObj`
• createCollection(opCtx, nss, cmdObj, idIndex, kind)
• createCollection(opCtx, nss, collectionOptions, idIndex)
• _createCollection(opCtx, nss, collectionOptions, optional<BSONObj> idIndex, optional)
  • Conditional handling of idIndex, generating a new `createIdIndex` parameter, and when userCreateNs() is called.
• DatabaseImpl::userCreateNS(opCtx, nss, collectionOptions, createDefaultIndexes, idIndex, fromMigrate)
• DatabaseImpl::_createCollection(opCtx, nss, collectionOptions, createDefaultIndexes, idIndex, fromMigrate)
  • Finally, the secondary creates the collection in the durable catalog