[SERVER-66474] Consider increasing number of shards in sharding passthrough suites Created: 16/May/22  Updated: 12/Dec/23

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

Type: Task Priority: Major - P3
Reporter: Pierlauro Sciarelli Assignee: Backlog - Catalog and Routing
Resolution: Unresolved Votes: 0
Labels: 12/12
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-66031 Command(s) hang when specifying colle... Closed
Assigned Teams:
Catalog and Routing
Participants:
Story Points: 2

 Description   

At the time of writing of this ticket, there are 38 sharding passthrough suites and only 24 of them are initializing more than 1 shard (by default num_shard=1).

$ git grep ShardedClusterFixture buildscripts/resmokeconfig/ | grep passthrough | cut -d':' -f1 | wc -l
38
 
$ for suite in `git grep ShardedClusterFixture buildscripts/resmokeconfig/ | grep passthrough | cut -d':' -f1`; do grep num_shards $suite; done | wc -l
24

This means that plenty of tests are being executed on a one-shard cluster whose behavior is pretty much similar to a plain replicaset, without spotting potential errors happening in multi-shard environments.

As an example of drawback, the jscore passthrough suite is only initializing one shard and did not catch a severe bug (SERVER-66031) introduced by SERVER-62455. Simply increasing the number of shards would have resulted in consistently hitting the problem.


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