At the beginning of validate_db_metadata_command.js there is some cleanup in case the test is running after the execution of some other jscore test. Additionally, we have some suites that overwrite the getCollection and drop shell's functions to automatically shard the collections (that is, some suites load the implicitly_shard_accessed_collections.js script before running, like multi_shard_local_read_write_multi_stmt_txn_jscore_passthrough). Finally, we also have tests that create collections that cannot be sharded, like for example geo_near_tailable.js, so, joining those 3 facts, we might encounter some suites running validate_db_metadata_command.js after some jscore test that creates a non shardable collection, which will definitely fail when accessing the collection, because a shardCollection command will be automatically issued.

Some ideas to solve this:

1. The validate_db_metadata_command.js could be blacklisted from all the suites that automatically shard collections, for example using the assumes_standalone_mongod tag commited recently
2. The validateDbMetadata command can have an optional filter parameter so on the test only a desired db is checked, as long as it ensures that the database name will be unique on each test execution