The node complains that the namespace "oplog.rs" doesn’t exist, and the test fails on the assert that tries to drop “oplog.rs”, here. This failure happens on an ephemeral storage engine, the ephemeralForTest storage engine. The node is restarted at some point, to take it from being a part of a replSet to being a standalone. However, in the process of restarting (i.e. shutting down and starting back up), the ephemeral storage engine is wiped and loses its “oplog.rs” collection (which it had when it was a part of a replSet), thus leading to the failure saying the namespace doesn’t exist when we attempt to drop it.
Other points: The InMemory WiredTiger storage engine does not fail this way, despite the reasoning given above. On requesting the database to drop the “oplog.rs” namespace, the database first performs a check to make sure dropping “oplog.rs” (or any other oplog namespace) is allowed and then proceeds to actually try and drop it. The InMemory WiredTiger storage engine therefore doesn’t actually try and drop this namespace, because it doesn’t get that far. This check isn't triggered when using the ephemeralForTest storage engine.
*Currently the node is started as a part of a replset and then restarted as a standalone. It might be better to just start up as a standalone directly and manually insert the oplog. This will guarantee that an oplog is present, and will also remove the test's reliance on methods like ReplicaSetTest's initiate() that aren't relevant. I think this is the best solution. See here *
Another solution is to surround the entire dropping portion of the test (lines 29 to 35) with a check to make sure “oplog.rs” exists first. This is a decent solution, because it accounts for any other storage engines that may have similar behaviors. Also, the purpose of the entire test is to see if forbidding the oplog works.
A third solution is to alter the ephemeralForTest storage engine to make it resemble the WiredTiger InMemory storage engine, but I don’t think this is a good approach. The InMemory WiredTiger storage engine has a bug (in supportsRecoveryTimestamp) which is why it behaves differently from the ephemeralForTest storage engine (mentioned above), and the ephemeralForTest shouldn’t adopt that bug as well.
Not all storage engines support the replSetResizeOplog command (see
SERVER-38356). In an attempt to maintain the same starting state for each iteration of the test (by maintaining the same oplog size), the replSetResizeOplog command is used but fails on the ephemeralForTest storage engine, which does not support the command.
A solution is to remove the line that tries to maintain uniformity at the start of each test. Since this is a part of the auth suite, it is unlikely that the particular size of the oplog even matters.
Another solution is to introduce the isWiredTigerOrInMemory() check - only when it is true, then issue the replSetResizeOplog command. Otherwise, just drop and create a new oplog. I think this is the best solution.