[SERVER-54662] validate_db_metadata_command.js is not compatible with some jscore tests under some suites Created: 19/Feb/21  Updated: 27/Oct/23  Resolved: 25/Mar/21

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Marcos José Grillo Ramirez Assignee: Arun Banala
Resolution: Gone away Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Operating System: ALL
Steps To Reproduce:

0. Load implicitly_shard_accessed_collections.js
1. Create a sharded cluster
2. Run geo_near_tailable.js
3. Run validate_db_metadata_command.js

Participants:
Linked BF Score: 43

 Description   

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



 Comments   
Comment by Arun Banala [ 25/Mar/21 ]

Looks like this issue is fixed by this commit.

Generated at Thu Feb 08 05:34:08 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.