[SERVER-30949] listCollections command through mongos should retry on NotMaster errors Created: 05/Sep/17  Updated: 27/Oct/23  Resolved: 15/Jan/23

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

Type: Task Priority: Major - P3
Reporter: Jack Mulrow Assignee: [DO NOT USE] Backlog - Sharding EMEA
Resolution: Gone away Votes: 1
Labels: open_todo_in_code, sharding-common-backlog
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-36325 mongos will not retry configsvrShardC... Closed
Related
related to SERVER-33514 send dbVersion on listCollections and... Closed
related to SERVER-72868 Complete TODO listed in SERVER-30949 Closed
Assigned Teams:
Sharding EMEA
Participants:

 Description   

Currently, the listCollections command on mongos uses DBClientReplicaSet::query, which does not retry on NotMaster errors.

This is a problem for concurrency stepdown suites (like the config stepdown suite introduced in SERVER-30677), that call listCollections through mongos as part of validating the state of the cluster between workloads, and because shardCollection, which is also called between workloads, involves calling listCollections and can fail if the config server has a stale view of the cluster.

The same is true for listIndexes, which uses the same cursorCommandPassthrough helper.



 Comments   
Comment by Tommaso Tocci [ 15/Jan/23 ]

This have been solved in SERVER-33514, since we made both listCollections and listIndexes commands to use the executeCommandAgainstDatabasePrimary helper method with Shard::RetryPolicy::kIdempotent.

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