[SERVER-41740] Test that listCollections and listIndexes against mongos behave correctly after movePrimary and database drop/recreate Created: 14/Jun/19  Updated: 27/Oct/23  Resolved: 01/Jul/19

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

Type: Task Priority: Major - P3
Reporter: Esha Maharishi (Inactive) Assignee: Janna Golden
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: Sharding 2019-07-01, Sharding 2019-07-15
Participants:

 Description   

(Original ticket name: "Make listCollections and listIndexes send databaseVersion")



 Comments   
Comment by Janna Golden [ 01/Jul/19 ]

Coverage already exists in jstests/sharding/database_versioning_safe_secondary_reads.js and database_and_shard_versioning_all_commands.js.

Comment by Esha Maharishi (Inactive) [ 18/Jun/19 ]

Actually, they seem to already send databaseVersion: both listIndexes and listCollections use the cursorCommandPassthrough helper, which attaches database version.

However, I'd like to use this ticket to make sure we have test coverage of listCollections and listIndexes in the presence of movePrimary and drop/recreate database. We have some in database_and_shard_versioning_all_commands.js, but that test specifies "skipProfilerCheck: true" for listCollections, which I think means the test doesn't actually check that the command sent dbVersion.

Note, move_primary_clone_test.js is related in that it checks listCollections and listIndexes output from shards after movePrimary, but I am more interested in making sure listCollections and listIndexes from mongos have the right output.

Generated at Thu Feb 08 04:58:32 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.