[SERVER-81580] Make kDefaultConfigCommandTimeout configurable and raise it in slow tests Created: 29/Sep/23  Updated: 05/Feb/24  Resolved: 16/Nov/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 7.3.0-rc0

Type: Improvement Priority: Major - P3
Reporter: Louis Williams Assignee: Janna Golden
Resolution: Fixed Votes: 0
Labels: new-eng, sharding-nyc-subteam3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
is duplicated by SERVER-84306 checkMetadataConsistency default maxT... Closed
Related
related to SERVER-81910 Consider making "maxAwaitTimeMS" for ... Backlog
Assigned Teams:
Sharding NYC
Backwards Compatibility: Fully Compatible
Sprint: Cluster Scalability 2023-11-13, Cluster Scalability 2023-11-27
Participants:
Linked BF Score: 133

 Description   

We've had a lot of tests start timing out because they are hitting this 30 second hard-coded timeout. Make the value configurable and considering raising it in some test suites so they don't time out as much.



 Comments   
Comment by Githook User [ 15/Nov/23 ]

Author:

{'name': 'jannaerin', 'email': 'golden.janna@gmail.com', 'username': 'jannaerin'}

Message: SERVER-81580 Add defaultConfigCommandTimeoutMS to config fuzzer
Branch: master
https://github.com/mongodb/mongo/commit/6d27f4f11e285da476c3afebdc145ee620a9a6cc

Comment by Githook User [ 10/Nov/23 ]

Author:

{'name': 'jannaerin', 'email': 'golden.janna@gmail.com', 'username': 'jannaerin'}

Message: SERVER-81580 Make kDefaultConfigCommandTimeout configurable
Branch: master
https://github.com/mongodb/mongo/commit/ced16c4a2f59654dd4ce519ad43f939766132e7d

Comment by Janna Golden [ 10/Nov/23 ]

judah.schvimer@mongodb.com ah yeah, I can look into doing that as well.

Comment by Judah Schvimer [ 09/Nov/23 ]

Should we also add this to the config fuzzer as a quick follow on?

Comment by Adi Zaimi [ 10/Oct/23 ]

We should also look at why these operations take > 30s (whether it is reasonable for them to do so).

Comment by Louis Williams [ 02/Oct/23 ]

The goal here is not to raise the timeout to make the failures go away entirely. But if this were configurable, it would be much easier to temporarily raise the timeout to reduce the failure rate while we have time to investigate the failures.

Generated at Thu Feb 08 06:46:53 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.