-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Cluster Scalability
-
Fully Compatible
-
ALL
-
Cluster Scalability 2024-6-10, Cluster Scalability 06/24/24
-
200
In test case #3, the test sets a failpoint that would hang shard0 during the execution of the shardsvr aggregate command. However, shard0 should instead be hanging sometime when the getMore command starts. This is because the goal of test case #3 is to wait until shard1 adds shard2 as a participant after the cluster aggregate starts. But that will never happen if shard0 hangs during the aggregate command. This is because how cluster aggregate works is that the mongos first needs to run a dummy aggregate command on all the shards to establish cursors. Then it runs a getMore command on the shards with those cursors to actually get/compute the result, which is when shard1 would actually add shard2 as participant.
See BF-33206 for more details.
- is related to
-
SERVER-91330 txn_participant_adds_additional_participants_with_aborts.js fails with with paused-forever failpoint
- Closed