txn_participant_adds_additional_participants_with_aborts.js should not hang shard0 during shardsvr aggregate command execution

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Fixed
    • Priority: Major - P3
    • 8.1.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • None
    • Cluster Scalability
    • Fully Compatible
    • ALL
    • Cluster Scalability 2024-6-10, Cluster Scalability 06/24/24
    • 200
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None

      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.

            Assignee:
            Israel Hsu (Inactive)
            Reporter:
            Wenqin Ye
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: