The code used at start up to inform the replication subsystem whether or not the storage engine supports read committed is incorrect. If the user has not specified a storage engine in the config file or at the command line, storageGlobalParams.engine will be set to wiredTiger, but in that scenario the actual storage engine is chosen based on the contents of the --dbpath directory. This scenario is detected by consulting the storageGlobalParams.engineSetByUser predicate, but in this case there is no way to find out the actual type of the storage engine at this point in time.

Unfortunately, the current implementation leads to bad behavior when configuring a replica set to act as a config server, because such sets should refuse to admit mmapv1 nodes as members.

This problem is related to SERVER-19739, and has the same challenge w.r.t. fixing it, as noted in the code comment linked above.